Configuration management system

Timeless with sequences

  • does not depend on temporal sequence of imperative applications - declarative
  • support temporal sequences through declarative state machines
  • dependency system built on top of the declarative state machines
  • static contradiction analysis - no two statements can declare state of same resource-states
  • resource-state data passing - some configuration input data can only be available after a resource-state has been reached, it should be accessible for resource-state configuration that depend on it
  • some states become invalidated by data passed from dependencies - e.g. server configuration has changed (is dirty) so the "configured/running" state of service is now "dirty/running" state and it has to be transitioned through "stop/reload" state to get back to "configured/running"


  • it is not possible to fully describe total state of the system:
  • would be partially possible with OS - like Nix or Guix which describe most of the OS state in declarative way already
  • external states cannot be fully described
  • configuration system needs only to declare interesting states and changes starting from some assumed initial system state
  • resource can start from later state and assert system was in that initial state: e.g. file can be asserted to already exist and if it does not we panic instead of creating it


  • dirty state problem: system is not in known initial state; imperative configuration would fail, declarative will determine state and apply transformations needed to bring it to desired state - can only fail if there are contradictions
  • why we have dirty state problem:
  • OS design: program environment is inherited and not know
  • external: state external resources to computer system cannot be know or controlled until queried
  • resetting to clear state is costly and should be avoided
  • temporal sequence problem:
  • there are temporal dependencies between resources - some resources need to be put in known state before others can (e.g. directory needs to exists before file can be put in it)
  • multiple resources states: some resources can have multiple states and need to be driven through state changes until desired state can be reached (e.g. network interface: down -> up -> running)
  • same resource can have dependency on it's previous states OR dependencies are state requirements on self or another resource(s) - so not resources but resource-states that are unique

Dirty state existing solutions:

  • VM images - always build new image from known clean state <- very expensive
  • Docker images - same as for VM, bit cheaper as it allows layers of premade state to be stacked
  • there cannot be an imperative solution for external states like networks, DNS, other external state-full services

Operational requirements:

  • one right way of doing things - otherwise code cannot be shared easily
  • debug-ability - easily link declarative statements to their corresponding imperative execution
  • declarative system generates imperative code: it should be possible to generate complete imperative checks and state transitions script applicable to system in any state that can be inspected and run independently
Assigned to
1 year, 2 months ago
1 year, 2 months ago
No labels applied.