KEP 94: Lifecycle Toolkit - Table Promotion Flow

[aaronmassicotte]

No description provided.

[mowies]

In general Keptn follows a GitOps approach which is fully declarative and always starts from a commit from whatever GitOps tool a user might use.
With this KEP, I see a change in that to a more imperative approach which would be a big paradigm shift for Keptn.

Why do you see a need to change that approach with this?
Wouldn't a potential "imperative" tool plus UI be more on the other side of the GitOps workflow, so, before the commit happens to a repo?

[aaronmassicotte]

In general Keptn follows a GitOps approach which is fully declarative and always starts from a commit from whatever GitOps tool a user might use. With this KEP, I see a change in that to a more imperative approach which would be a big paradigm shift for Keptn.

Why do you see a need to change that approach with this? Wouldn't a potential "imperative" tool plus UI be more on the other side of the GitOps workflow, so, before the commit happens to a repo?

Not at all. The promotion flow can be implemented while respecting GitOps entirely. In order to implement this, you are required to 1) display a dashboard of visible artifacts which can be promoted and 2) display which artifacts exist in what environment. All of this information comes from VCS, so the initial state is GitOps. Changes are not done to the cluster directly, but to the underlying GitOps code via Git runners and webhooks, for example. It could be anything really. In order to promote, you trigger a job which updates the underlying code, and then your continuous deployment will do the rest, then the dashboard can display a new state with the "promoted" artifact