patent strategy

foo-fighters.txt

goals:
- timeline/strategy for refactor (what can we replace first)
- destination abstractions
- what can we reuse that's already in place?


update deployment flow:
1. load manifest as hash
2. fetch (cloud config and) runtime config
3. acquire lock
  a. (create new variable set)
  b. create manifest object
  c. create deployment plan
     ... assembler.bind_models



cloud check flow:
~


---
current entities of note
. "manifest hash" -> Manifest object -> Changeset object
. DeploymentPlan::PlannerFactory
. DeploymentPlanner, which is created using these extra options:
      - job_states, tags?, which affect terminal state of new deployment
      - fix, recreate, canaries, max_in_flight, skip_drain which affect deployment process
. Assembler, which seems to be responsible for figuring out how a deployment plan relates
        to existing and upcoming models, like instances
        has components:
        - job migrator
        - instance repo -> fetches existing instances
        - index assigner
        - instance plan(ner) -> deployment plan to instance plan

~~~concepts we can preserve maybe~~~
"repos" are entities responsible for checking DB for current state of the world.
- we will need these methods to do our reconciliation step.



~~~~Proposed new concept layout (may not encode all of these in code, but mentally)~~~~
"manifest"/"cloud config"/"runtime config" stays the same
"claim" -> a resource needed/mapping of resource usage to instance etc,
   (atoms of the manifest/CC/RC entities)
"digression" -> the changes specified outside of manifest, i.e. detached instance
"patent" -> a union of claims between manifests, CC, RC, and digressions
"precedent" -> the universe as it exists today, described as claims + metadata
"mutation" -> an action that must be taken to change the embodiments
## "limitation" -> a set of mutations/mutation scopes to ignore
"obligation" -> total set of mutations required after diffing the patent with the embodiments,
                described **with temporal properties** i.e. stages of precedence, or maybe flow


Creating a deployment then just becomes performing an update upon an empty set of claims.
Update looks like:
- compose the patent (can use partial manifest diffs if we want)
- determine the embodiments
- "subtract" embodiments from the patent to determine the obligation
- begin at root node/first stage/etc of the

CCK looks like:
- patent is just the old patent
- embodiments check to see what's wrong
- proceed like business as usual

The hard part here would be devising a way of producing a minimal obligation, then partitioning
  the obligation into a timeline (tradeoff between flexible and entangled -- i.e. can be series
  of stages, or complex dependency graph)


-> to do this, we need to define the "mutator" for create-vm
->      the "subtract embodiments from patent (i.e. compute diff as mutations)" algorithm
->      structural spec for an obligation
"given a manifest change, i should be able to compute an obligation that entails
      a number of VMs that need to be created"

Mutation -> steps for each stage of deployment
Create VM/or no
Transmit job bits stage
Vm deletion stage

start -> create vm -> "creation stage done" -> download blobs -> stop other -> transfer disk -> start this -> done
                   -> "creation stage done" -> download blobs -> stop other -> transfer disk -> start this -> done



CLAIM is bounded in scope by:
1. as big as possible
2. never so big that the sensible transition from before to after is changing it

MUTATION is bounded by:
no smaller than an action that should show up in user-oriented "and then we will do..."
no larger than the claim which necessitates it
will always include either CPI or agent call?

OBLIGATION should be minimal


claim ->
  vm_fancytype (instance_group_name/migrated_from, networks, stemcell, vm_type)
  disk(_fancytype?) (instance_group_name/migrated_from, size)
  instance_fancytype (instance_group_name, running jobs..., vm_fancytype1)


changes to instance groups?
"instance group"/"instance"
an association in the embodiments -> correlates to exactly one "instance"
and zero or more fancytyped claims