feat(docs): add ADR for Plugin lifecycle #14
Conversation
|
This PR is stale because it has been open for 45 days with no activity. |
|
This PR was closed because it has been inactive for 14 days since being marked as stale. |
Signed-off-by: Akshay Iyyadurai Balasundaram <[email protected]>
- Adds a draft option for using Flux with Flagger to managing the plugin lifecycle --------- Signed off by: Simon Olander ([email protected])
This adds a draft idea for how work could progress and which steps we would need to take to roll out a new plugin --------- Signed off by: Simon Olander ([email protected])
| | [decision driver c] | -- | Bad, because [argument c] | | ||
| | [decision driver d] | o | Neutral, because [argument d] | | ||
|
|
||
|
|
There was a problem hiding this comment.
| ### [`UpdateDelay` field on `PluginPreset.Spec`] | |
| Description: Like PluginPreset Orchestrator idea with no explicit version pinning | |
| In this approach the PluginPreset would be extended to allow an optional `UpdateDelay` value (within a defined range?). This value would default to `0`. (need to decide on Syntax... CronJob-like?) | |
| This would provide the possibility to stagger rollouts without the need for version pinning. | |
| The `PluginPreset` Controller would need to maintain the timestamp of the last Update of the `PluginDefinition`. If `now - UpdateTimestamp > UpdateDelay` the controller will perform the update. It will set an `UpdateDelayedCondition` otherwise to inform the User of a pending Update. We might extend this Condition to contain the `diff` of the changes. |
@IvoGoman @kengou (please mention any other decision drivers)
This might be a first step to a simple approach to solve the pressing issues. We might want to keep (opinionated) simplicity on this one. Forcing Updates, but allowing delays and therefore staggering. A little bit like the Gardener Way?
We might even decide to set the PluginPreset into an Error state to make sure a delayed update is perceived. Or we introduce a more generic WarningReceivedCondition on all our resources, so the UI is able to display these.
We do have to think what happens if an new Update happens within the UpdateDelay period. If the Controller just updates the timestamp the whole process starts again, but the running Plugin will be 2 versions behind. It would make sure we only update the PluginPreset if we have the Update running without interruption for the complete UpdateDelay period.
IvoGoman
changed the title
TL;DR;
This ADR proposes to introduce PluginDefinitionRevisions to enable version pinning on PluginPreset and Plugin resources. PluginPresets will support semantic version constraints, while Plugins, due to technical limitations, will only support concrete versions.
This will enable to stagger a rollout of a new PluginDefinition version by using a concrete version tag on the PluginPreset referring to this PluginDefinition. There is still the option to perform automatic upgrades as before.
Greenhouse will provide the means to use any given CD/GitOps/etc. way to deploy these manifests, but it will not provide an out of the box way to deploy the Greenhouse manifests of an Organization into it's namespace.
Garbage-collection of these revisions is proposed to delete the oldest unused revision/version over a count of
maxRevision. This way gradually over time older revisions can be removed as soon they are no longer used.