Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • stork stork
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 220
    • Issues 220
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 14
    • Merge requests 14
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • storkstork
  • Issues
  • #599
Closed
Open
Created Oct 27, 2021 by Tomek Mrugalski@tomek🛰Owner

Design configuration management

Up until 1.0, Stork was a dashboard - monitoring and displaying various things, but not changing any configuration of either Kea or BIND.

This ticket is about designing the ability to manage (change) configuration. Here are some aspects to consider:

  1. the configuration can be pushed with config-set. Should it be also stored locally with config-write? (pro: system is more stable, as it doesn't require stork agent to be up and running and re-push after restart, con: how to handle read-only systems? how to know where the config is supposed to be written? it depends on the startup scripts which config will be loaded).
  2. reverting changes
  3. audit trail (who made the changes and when, what kind of changes, which servers were affected)
  4. scheduling changes (this may be a future mechanism, but the solution should be extensible enough for its future implementation). The good usecase here prepare complex changes in advance and then deploy them at convenient time.
  5. hook dependence - some mechanisms will work only if the premium hooks are in place (e.g. subnet_cmds, host_cmds)
  6. extensibility - this is probably an entirely separate topic of how to do optional components (hooks in Stork)

UPDATE: requirements, design.

Edited Dec 28, 2021 by Tomek Mrugalski
Assignee
Assign to
Time tracking