Open joelanford opened 2 years ago
Another option that @exdx mentioned would be to leave cluster apply functionality out of the Combination
controller and delegate to another controller to actually deploy the rendered combination to the cluster.
make both the Template and Combination immutable
Even that might not be enough. I could create a Template
and Combination
referencing that template, and then delete the Template
and replace it with a new one of the same name. It seems like we'd have to avoid re-rendering the Combination
from its Template
after the first rendering succeeds.
make both the Template and Combination immutable
Even that might not be enough. I could create a
Template
andCombination
referencing that template, and then delete theTemplate
and replace it with a new one of the same name. It seems like we'd have to avoid re-rendering theCombination
from itsTemplate
after the first rendering succeeds.
This is something that Nick brought up pretty early on. We could create a hash of the original template and if doesn't match what the Combination is expecting we don't apply it. Thoughts?
I think that would solve the technical problem, but IMO that would be a pretty wonky user experience.
Thinking through a scenario here:
Template
named foo-tmpl
(with UID 1)Combination
named foo-combo
(with UID 1)foo-combo
from foo-tmpl
and applies it to the clusterfoo-tmpl
(open question: what happens to foo-combo
's on-cluster resources here?)foo-tmpl
(with UID 2 now) (open question: what happens to foo-combo
's on-cluster resources here?)One way to answer this that avoids upgrades happening is that in step 4, the Combination controller treats a "template not found" error (because it was just deleted) as an empty template and then deletes everything it was managing. Then in step 5 when a new foo-tmpl
shows up, nothing is on the cluster so step 5 is the same as step 2 (i.e. just create everything).
So TL;DR: One solution is:
Template
objects are immutableCombination
objects are immutableCombination
.
If a combo
Template
contains an object that has complex upgrade semantics (e.g. CRDs, workloads, maybe PVs/PVCs), how does a comboCombination
handle those upgrades gracefully?Should we build these APIs to specifically preclude upgrades from happening (e.g. by forcing the user to delete the
Combination
and create a replacement to trigger a delete/recreate flow instead of an in-place update)?To do that, would we need to make both the
Template
andCombination
immutable?