From 34a4a16cd6bd42a4232999874acc64b7cdaa2ab6 Mon Sep 17 00:00:00 2001 From: Moritz Wiesinger Date: Thu, 1 Feb 2024 10:35:24 +0100 Subject: [PATCH 1/4] add KEP Signed-off-by: Moritz Wiesinger --- text/0098-promotion-phase.md | 42 ++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 text/0098-promotion-phase.md diff --git a/text/0098-promotion-phase.md b/text/0098-promotion-phase.md new file mode 100644 index 0000000..bdbd56e --- /dev/null +++ b/text/0098-promotion-phase.md @@ -0,0 +1,42 @@ +# Promotion Phase for GitOps use cases + +Add a new lifecycle phase after post deployment dedicated to GitOps promotion tasks. + +**State: DRAFTING** + +## Motivation + +Since one of the main use cases for Keptn is enhancement of GitOps workflows, we should have bigger focus on that +by introducing a dedicated stage after the post-deployment phase for GitOps promotion tasks. +This will make it much clearer for Keptn users how to set up their GitOps-assisted workflows in multi-stage +environments. + +## Explanation + +The new promotion phase can be used by adding a list of references to `KeptnTaskDefinition` resources to a new field +called `promotionTasks` inside the `KeptnAppContext` CRD. Keptn will use this list the same way as for other phases +like post-deployment and execute the referenced tasks in parallel using Kubernetes Job resources. + +## Trade-offs and mitigations + +No real drawbacks come to mind, except some slight slowdown in progression of the lifecycle since the new phase +needs to be executed and the lifecycle-operator needs to check if any tasks need to be run. + +## Breaking changes + +This KEP would not have any breaking changes. The `KeptnAppContext` CRD would get an additional field called +`PromotionTasks` which contains a list of references to `KeptnTaskDefintion` resources that should be executed in this +phase. + +## Prior art and alternatives + +The alternative to this KEP is that users re-purpose the post-deployment phase for promotion, which would limit +flexibility since users lose the option to not promote when post-deployment tasks fail. + +## Open questions + +For now, none. + +## Future possibilities + +For now, none. From fe18c7462d8044c574ffaae063448e3616a9a2e0 Mon Sep 17 00:00:00 2001 From: Moritz Wiesinger Date: Thu, 1 Feb 2024 12:34:19 +0100 Subject: [PATCH 2/4] Update text/0098-promotion-phase.md Co-authored-by: Giovanni Liva Signed-off-by: Moritz Wiesinger --- text/0098-promotion-phase.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0098-promotion-phase.md b/text/0098-promotion-phase.md index bdbd56e..697b8e2 100644 --- a/text/0098-promotion-phase.md +++ b/text/0098-promotion-phase.md @@ -7,7 +7,7 @@ Add a new lifecycle phase after post deployment dedicated to GitOps promotion ta ## Motivation Since one of the main use cases for Keptn is enhancement of GitOps workflows, we should have bigger focus on that -by introducing a dedicated stage after the post-deployment phase for GitOps promotion tasks. +by introducing a dedicated stage after the post Application deployment phase for GitOps promotion tasks. This will make it much clearer for Keptn users how to set up their GitOps-assisted workflows in multi-stage environments. From ad05090c5ac20dcac269cd4c1d138da6175056f7 Mon Sep 17 00:00:00 2001 From: Moritz Wiesinger Date: Thu, 1 Feb 2024 13:29:52 +0100 Subject: [PATCH 3/4] add open question about failure state Signed-off-by: Moritz Wiesinger --- text/0098-promotion-phase.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/text/0098-promotion-phase.md b/text/0098-promotion-phase.md index 697b8e2..a642aba 100644 --- a/text/0098-promotion-phase.md +++ b/text/0098-promotion-phase.md @@ -35,7 +35,12 @@ flexibility since users lose the option to not promote when post-deployment task ## Open questions -For now, none. +One open point is how the new phase influences the failure or passing state of the overall deployment of a user's +application. +What happens when everything passes, but a promotion task fails? +My suggestion would be to let users configure this through some settings. Similar to the non-blocking behaviour +suggested in [#1934](https://github.com/keptn/lifecycle-toolkit/issues/1934), users could then decide +if a failing promotion task should fail the overall deployment. ## Future possibilities From 66fa028833f1a5ca45af373d7cc88ab750907ed0 Mon Sep 17 00:00:00 2001 From: Moritz Wiesinger Date: Tue, 6 Feb 2024 08:31:38 +0100 Subject: [PATCH 4/4] review Signed-off-by: Moritz Wiesinger --- text/0098-promotion-phase.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0098-promotion-phase.md b/text/0098-promotion-phase.md index a642aba..cebec5b 100644 --- a/text/0098-promotion-phase.md +++ b/text/0098-promotion-phase.md @@ -6,8 +6,8 @@ Add a new lifecycle phase after post deployment dedicated to GitOps promotion ta ## Motivation -Since one of the main use cases for Keptn is enhancement of GitOps workflows, we should have bigger focus on that -by introducing a dedicated stage after the post Application deployment phase for GitOps promotion tasks. +By introducing a dedicated stage after the post Application deployment phase for promotion tasks, we will +enable users to automatically promote their apps into another stage/cluster/environment. This will make it much clearer for Keptn users how to set up their GitOps-assisted workflows in multi-stage environments.