- 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.
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.
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).
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).
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.
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