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"

Completeness:

• 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

Problems:

• 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