MVP description of parts for foo-mechanism/hotswap-strategy

compilation.md

Compilation

Claims

package claim - A package claim will contain the current package version and the stemcell

Patent Counsel

The patent counsel will create package claims for the new version number and/or stemcell version

Inspector

Will generate embodiment package claims based on the stemcell and version number of used package in instance groups

Reconciler

For any package claims which are in the patent claim, but not in the embodiment the reconciler will determine if the package has been previously compiled for that stemcell, and exists in the blobstore, or will create compilation mutations.

Executor

The executor will either compile the packages and insert them into the blobstore or do nothing. If the executor is compiling packages, it will need to acquire a compilation locks in order to ensure multiple deployments are not compiling the same package at the same time. See bosh/src/bosh-director/lib/bosh/director/deployment_plan/steps/package_compile_step.rb for inspiration, shouldn't have to change much. Could even have executor have two steps, 'Compile', and 'Deploy', with 'Compile' step (at least initially) basically remaining unchanged.

Reuse compilation vms

When reuse compilation vms is enabled, the compilation vms will pick which package to compile based off a queue which was created by the reconciler.

Do not reuse compilation vms

The reconciler will create nodes in the tree for each compilation depending on the number of compilation vms as defined in the manifest.

metaphor name proposition

~~~~Proposed new concept layout (may not encode all of these in code, but mentally)~~~~

"manifest"/"cloud config"/"runtime config" stays the same
 old name: "claim", new name: "material" -> a resource needed/mapping of resource usage to instance etc,
   (atoms of the manifest/CC/RC entities)
old name: "digression", new name: "addition" -> the changes specified outside of manifest, i.e. detached instance
old name: "patent", new name: "blueprint" -> a union of claims between manifests, CC, RC, and digressions
old name: "embodiment", new name: "floorplan" -> the universe as it exists today, described as claims + metadata
old name: "mutation", new name: "remodel" -> an action that must be taken to change the embodiments
## "limitation" -> a set of mutations/mutation scopes to ignore
old name: "obligation", new name: "construction plan" -> total set of mutations required after diffing the patent with the embodiments,
                described **with temporal properties** i.e. stages of precedence, or maybe flow

old name: "patent counsel", new name: "architect"
old name: "inspector", new name: "inspector"
old name: "reconciler", new name: "foreman"
old name: "executor", new name: "assembler"

mvp patents.md

MVP for VM creation Only

What the minimum claims that need to be defined are

• VM claims:
• • any changes cloud config sections which affect this vm_type
• • network(s)
• • vm_type
• • stemcell change
• • changes to instance_group name

note that we could separate into a story for each "category" of change to a patent, to keep things even more minimal, if we wanted. i.e., "when I deploy a manifest configured with update_strategy: hot_swap, and an instance has changed its specified stemcell in the new manifest, it should get a VM created up-front before proceeding with normal deploy" could be an alternative first story.

mutations needed

create-vm, parameterized with relevant information associate-vm-to-instance, though this might be included in the create-vm. This might not even be considered MVP for this story depending on acceptance criteria.

Components needed

Patent Counsel*

This component should be able to look at a manifest and determine its total set of VM claims. Note that "new"ness is not of any concern to the patent counsel.

• if dmitriy requires that stop --hard is respected for the first story, then we also need this to account for digressions (and we will need to define said digressions).

Inspector

It should use things like InstanceRepo to inspect the present state of the cloud and construct an embodiment.

• Eventually, the embodiment will include more information than the patent. In particular, it knows about existing instance models in the instance group (i.e. identifies them by their GUIDs), and correlates those to appropriate existing VM claims. This collection of associations is part of the embodiment, whereas the patent doesn't care about specific instance info.
• For the first story, this thing only needs to be able to detect existing VMs (doesn't even care about existing instances yet).

Hot-Swap Reconciler

this is a component which can look at a patent contrived from a manifest, and look at an embodiment, and determine the number, cloud details, instance association, etc for any NEW vms that are needed; and output them in obligation form. Dmitriy may consider it required that --recreate becomes known to the reconciler in its figuring, given that this flag does not affect the patent.

Executor

this should be able to read an obligation which only includes VM creation steps and enact those steps upon a cloud deployment. It should always do the creation in batch (when we backport old strategy to new mechanism, it would need to be able to consume an obligation which says to do them in serial).

• this and all names are open for improvement † talk to RDR about his brilliant observation