...
- Store the currently running state
- Allow to prepare the new intended state
- Move the current state towards the new intended state - this means to:
- Determine "diff" between the current and the new state
- Find ordering of Create/Modify/Delete operations that respects the dependencies
- Run operations
- . Erik: is there some assumption that a modification to a parent (e.g., vlan above) also means there is a need to run a modify, or a delete+create, of a child? There might be some cases where the parent modify results in a delete and recreate which would implicitly delete e.g., routes using that interface
- Run operations. Erik: Can it handle Run that needs to be asynchronous e.g., the nim case of asking domainmgr to get back eth1 from pciback? Would it make sense for the reconciler to return a list of functions to call and have the caller execute those functions? Then the functions can return done, error, waitforX
- Store and expose any errors returned by Create/Modify/Delete operations
For the step 1., the graph must also allow to represent configuration items managed by microservices other that the one that owns the graph (let's label them as "external"). For those, the graph will never trigger Create/Modify/Delete operations and will use them only for the purposes of dependency management (e.g. create A only after another microservice has already created B).
...