Problems and Questions:
- Cross-pollution of duties between objects (calculating old vs new state, building changeset, applying changes)
- Cost of refactoring current abstractions vs overhauling deploy/CCK to wholly use new system a. Some code in current flow (e.g. NetworkPlanner, which is primarily concerned with handling static and VIP networking) is not going to be used when hot-swap is turned on. b. We could refactor only hot-swap relevant portions to use patent strategy, but we then will have to support two different systems, which will likely need to interact cleanly; we would need to have a method of converting information between the two systems. c. Edge cases may arise while writing the new patent strategy which break the paradigm. The architecture will need to be vetted more thoroughly, to ensure that we aren't forced to rewrite the new code or sacrifice the abstraction.
- Related to #1, the changeset is constructed throughout the flow rather than being finalized before being passed to the updaters
- Should the patent strategy be viewed as a new in-code architecture, or as a philosophical system for describing behavior + some architecture changes?
- 3-Tier system (expand on this)
- Current actions are not atomic (VMCreator attaches disks, updates settings, deletes VMs, applies state)
- CCK flow is far too messy and removed from both current abstractions and patent strategy. General overhaul probably the best option 8?. Claims seem prone to turning into ThingDoers that invoke a bunch of single-method mutations in lieu of private methods, which means we wouldn't actually solve the issue. a. Other direction (make claims less monolithic) likely to result in numerous permutations of claims that differ by only one mutation, leading to class explosion. b. On a related note, depending on the update strategy, there will be different rules for interleaving cpi and agent calls between new and old vms. This will cause claims to have to handle mutations for theses cases and may cause mostly redundant code. c. If we make the mutation set of a claim dynamic, they lose value as an abstraction for users and developers because assumptions cannot safely be made about that claim's behavior.
Thoughts:
- Using dummy (log only) CPI, agent, DB for more realistic dry-run output? a. Has benefit of actually walking code paths instead of relying on calculated changeset (dependency tree) being a fully accurate representation of what will be done
- Refactor the current objects into smaller single unit responsibility objects. Ensure that objects do not mix manifest/spec parsing and agent/cpi actions.
- job template rendering should be a self contained atom (see PQ#6, T#2)
- The current abstractions of Planner, SpecParser, and Models which correspond roughly to the Reconciler, Patent, and Embodiment concepts are relatively well organized and offer less benefit from converting them completely to the patent strategy concepts.
Rough mapping of current abstractions -> patent strategy abstractions
Planner ~= Reconciler (Planner shares some facets of Patent) SpecParser ~= Embodiment/Patent Models ~= Embodiment (Does not seem to encode non-manifest modifications) X Mutation X Claim Updater != Executor <-- most important
3 Stage System (Should not be interpreted as a counterproposal to Patent Strategy, but as a higher-level diagram of where we want to end up)
- Determine changes from new state objects (Manifest, CC/RC/CPIC), persisted state, and out-of-band modifications ---CCK starts here (kind of)---
- Use output of stage 1 to build up set of necessary actions for each instance ----Dry-run stops here----
- Apply the output of stage 2. ---Update and CCK stop here---