Plan Lifecycle KEP

[kensipe]

We need plan lifecycles defined for KUDO. There is a lot to define, justifying a KEP

What is to be defined / decided:

• Is a plan re-entrant? should an annotation allow opt-in or opt-out ability?
• should a plan block all other plans... or should we have plan properties that define anti-affinity like behavior. such as a list of plans that can't run while this plan is running.
• we need to define a way to force a step / plan to completion or to stop a plan / clear a run
• similarly we may want to "skip" a step (that is blocked but handled external to kudo) or instance a pipe task step is failing and a user updates a secret and wants to skip that step to continue thru the rest of the plan.
• cleanup is a finalizer (but it is likely a cleanup of "deploy"), perhaps other plans would like to add to the finalizers (if "plan2" is ever run, than "plan2-cleanup" should be run as a finalizer). Perhaps this refactors how the current "cleanup" is defined.

[ANeumann82]

On the same topic:

• Does it make sense to have a plan execution "queue" or are there too many side effects? Thinking about something like:

  k kudo plan trigger backup -p WHAT=node1
  k kudo plan trigger backup -p WHAT=node2
  k kudo plan trigger backup -p WHAT=node3

  (this might be solvable with parallel execution of some plans... Hmmmm)

[alenkacz]

@ANeumann82 you can always have a queue outside of k8s api. I feel like queue is very much outside the k8s style of APIs so I would rather design it somewhere else. But just my personal opinion :)