From e805ed594a9e7ea8bec8157e2b0501ff6fb84f2a Mon Sep 17 00:00:00 2001 From: Joseph Beck Date: Fri, 15 Nov 2024 16:29:02 -0800 Subject: [PATCH 01/13] Add WIP HIP for a proposal to add a sequencing featureset to Helm installations and upgrades. Signed-off-by: Joseph Beck --- hips/hip-00xx-sequencing.md | 60 +++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 hips/hip-00xx-sequencing.md diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md new file mode 100644 index 00000000..4c0ef9a9 --- /dev/null +++ b/hips/hip-00xx-sequencing.md @@ -0,0 +1,60 @@ +--- +hip: 9999 +title: "Better Support for Resource Creation Sequencing" +authors: [ "Joe Beck " ] +created: "2024-11-15" +type: "feature" +status: "draft" +--- + +## Abstract + +When an applicaiton requires dependencies to be spun up first before the application can start. Writing this sequencing into a helm chart today is very tedious using hooks and weights to sequence the resources, or some built-in application safety checks at runtime to achieve similar sequencing. I'd like to propose helm has a better sequencing mechanism that allows chart developers to specify dependency chains between resources, that doesn't leverage the current hooks and weights system. + +I'm not sure what exactly the best implementation of this would be, but my first naive approach would be a "depends on" system where a chart developer can specify something such as "this deployment `foo` depends on job `bar` completing before it is created". Then during installation/upgrades, helm would resolve the entire dependency chain and add resources to the cluster in the chain order. + +## Motivation + +Today, to accomplish any kind of sequencing you have two options. The first is leveraging hooks and weights, the second is building the sequencing into the application itself. + +Using hooks and weights can be a tedious process, as for example, running one pre-install job at weight 0, may require other resources such as config maps, secrets, and service accounts, to be created at weight "-1" to ensure the job can run. In a lot of cases, those same resources that exist at weight "-1" will need to be duplicated and exist outside of the context of the hook, which adds bloat to the chart installation. Additionally, for mor complex use cases, the weight system on hooks can become very tedious to maintain and get right on the chart developer side. + +Building the sequencing into the application may reduce complexity in the chart itself, but it significantly increases complexity of the application when safety checks or the equivalent of `while(database not ready) { thread.sleep() }` need to be added just to satisfy the helm deployment use case, when that may be one of many ways to deploy an application. + +By providing a mechanism to the chart developer that allows them to explicitly determine when resources are deployed to a cluster, we work around both of these issues, by reducing applicaiton complexity, and reducing the need to leverage hooks. + +## Rationale + +TBD upon deciding on a design. + +## Specification + +TBD upon deciding on a design. + +## Backwards compatibility + +TBD upon deciding on a design. + +## Security implications + +TBD upon deciding on a design. + +## How to teach this + +TBD upon deciding on a design. + +## Reference implementation + +N/A + +## Rejected ideas + +N/A + +## Open issues + +- The exact design of how Helm 4 should implement such a sequencing mechanism still needs to be determined. + +## References + +N/A \ No newline at end of file From 3d754ea509a81c2931c937f5389a1dbd37492023 Mon Sep 17 00:00:00 2001 From: Joe Beck Date: Wed, 27 Nov 2024 10:55:54 -0800 Subject: [PATCH 02/13] cleanup sequencing hip and flesh out implementation proposals Signed-off-by: Joe Beck --- hips/hip-00xx-sequencing.md | 109 +++++++++++++++++++++++++++++++----- 1 file changed, 95 insertions(+), 14 deletions(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index 4c0ef9a9..5c90d3c9 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -9,35 +9,115 @@ status: "draft" ## Abstract -When an applicaiton requires dependencies to be spun up first before the application can start. Writing this sequencing into a helm chart today is very tedious using hooks and weights to sequence the resources, or some built-in application safety checks at runtime to achieve similar sequencing. I'd like to propose helm has a better sequencing mechanism that allows chart developers to specify dependency chains between resources, that doesn't leverage the current hooks and weights system. - -I'm not sure what exactly the best implementation of this would be, but my first naive approach would be a "depends on" system where a chart developer can specify something such as "this deployment `foo` depends on job `bar` completing before it is created". Then during installation/upgrades, helm would resolve the entire dependency chain and add resources to the cluster in the chain order. +This HIP is to propose a new featureset in Helm 4 to provide Helm developers a well supported way of defining what order chart resources and chart dependencies should be deployed to Kubernetes. ## Motivation -Today, to accomplish any kind of sequencing you have two options. The first is leveraging hooks and weights, the second is building the sequencing into the application itself. - -Using hooks and weights can be a tedious process, as for example, running one pre-install job at weight 0, may require other resources such as config maps, secrets, and service accounts, to be created at weight "-1" to ensure the job can run. In a lot of cases, those same resources that exist at weight "-1" will need to be duplicated and exist outside of the context of the hook, which adds bloat to the chart installation. Additionally, for mor complex use cases, the weight system on hooks can become very tedious to maintain and get right on the chart developer side. +Today, to accomplish resource sequencing you have two options. The first is leveraging helm hooks, the second is building required sequencing into the application (via startup code or init containers). The existing hooks and weights can be a tedious to build and maintain for Helm developers, and built-in app sequencing can unecessarily increase complexity of a Helm application that needs to be maintained by Application Developers. Helm as a package manager should be capable of enabling developers to properly sequence how their applications are deployed, and by providing such a mechanism to developers, this will significantly improve the Helm and Application developer experiences. -Building the sequencing into the application may reduce complexity in the chart itself, but it significantly increases complexity of the application when safety checks or the equivalent of `while(database not ready) { thread.sleep() }` need to be added just to satisfy the helm deployment use case, when that may be one of many ways to deploy an application. - -By providing a mechanism to the chart developer that allows them to explicitly determine when resources are deployed to a cluster, we work around both of these issues, by reducing applicaiton complexity, and reducing the need to leverage hooks. +Additionally, Helm currently doesn't provide a way to sequence when chart dependencies are deployed, and this featureset would ideally address this. ## Rationale -TBD upon deciding on a design. +### Proposal 1: Annotations +This design was chosen due to simplicity and clarity of how it works for both the Helm developer and Application Operator + +### Proposal 2: Weighted Resouces (without hooks) +This design was proposed as an alternative that functions very similarly to hooks today, to provide the same sequencing functionality outside of the scope of hooks. ## Specification -TBD upon deciding on a design. +### Proposal 1: Annotations +At a high level, allow Chart Developers to assign annotations to both their Helm templated resources and Helm chart dependencies that Helm then uses to generate a deployment sequence at installation time. Three new annotations would be added to enable this desribed next. + +- `helm.sh/layer`: Declare a layer that a given resource belongs to. Any numebr of resources can belong to a layer. +- `helm.sh/dependson/layer`: Declare a layer that must exist and in a ready state before this resource can be deployed. +- `helm.sh/dependson/chart`: Declare a chart dependency that must exist and in a ready state before this resource can be deployed. + +A layer would not be considered "ready" and the next layer installed until: +- all jobs in the layer are DONE +- all other resources in the layer are READY + +#### Example: +``` +# resource 1 +metadata: + name: foo + annotations: + helm.sh/layer: layer1 +--- +# resource 2 +metadata: + name: bar + annotations: + helm.sh/layer: layer2 + helm.sh/dependson/layer: layer1 +--- +# resource 3 +metadata: + name: fizz + annotations: + helm.sh/layer: layer3 + helm.sh/dependson/layer: layer1 + helm.sh/dependson/chart: someChartDependency +``` +In this example, Helm would be responsible for resolving the annotations on these three resources and deploy all resources in the following order: + +``` +layer1: [foo] + || + || [someChartDependency] + || || + \/ || +layer2: [bar] || + \\ // + \/ \/ +layer3: [fizz] +``` + +### Proposal 2: Weighted Resouces (without hooks) + +Expand on the the weight capabilities of hooks, but allow them to be defined outside of the context of hooks for the chart. Add a new annotation `helm.sh/weight` that helm then uses to order when resources are deployed based on the same weighting rules that hooks use today. + +#### Example: +``` +# resource 1 +metadata: + name: foo + annotations: + helm.sh/weight: "-2" +--- +# resource 2 +metadata: + name: bar + annotations: + helm.sh/weight: "-1" +--- +# resource 3 +metadata: + name: fizz + annotations: + helm.sh/weight: 0 +``` +In this example, Helm would be responsible for resolving the annotations on these three resources and deploy all resources in the following order: + +``` +-2: [foo] + || + \/ +-1: [bar] + || + \/ +0: [fizz] +``` ## Backwards compatibility -TBD upon deciding on a design. +Helm will continue to deploy all resources and dependencies at once, as adding the above defined annotations is when the installation behavior would change. ## Security implications -TBD upon deciding on a design. +None. ## How to teach this @@ -53,7 +133,8 @@ N/A ## Open issues -- The exact design of how Helm 4 should implement such a sequencing mechanism still needs to be determined. +- Choose between Proposal 1 and Proposal 2 +- Should this featureset take into account allowing Helm Developers to declare custom "readiness" definitions for a given layer, besides the default? ## References From 78075e28daef0d50209bdf56868a7622cd30f7b5 Mon Sep 17 00:00:00 2001 From: Evans Mungai Date: Thu, 28 Nov 2024 22:58:59 +0000 Subject: [PATCH 03/13] Additional information - Seuencing logic - Readiness logic Signed-off-by: Evans Mungai --- hips/hip-00xx-sequencing.md | 72 ++++++++++++++++++++++++++++++------- 1 file changed, 60 insertions(+), 12 deletions(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index 5c90d3c9..66eb423b 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -1,7 +1,7 @@ --- hip: 9999 title: "Better Support for Resource Creation Sequencing" -authors: [ "Joe Beck " ] +authors: [ "Joe Beck ", "Evans Mungai " ] created: "2024-11-15" type: "feature" status: "draft" @@ -20,7 +20,7 @@ Additionally, Helm currently doesn't provide a way to sequence when chart depend ## Rationale ### Proposal 1: Annotations -This design was chosen due to simplicity and clarity of how it works for both the Helm developer and Application Operator +This design was chosen due to simplicity and clarity of how it works for both the Helm developer and Application Operator ### Proposal 2: Weighted Resouces (without hooks) This design was proposed as an alternative that functions very similarly to hooks today, to provide the same sequencing functionality outside of the scope of hooks. @@ -28,18 +28,18 @@ This design was proposed as an alternative that functions very similarly to hook ## Specification ### Proposal 1: Annotations -At a high level, allow Chart Developers to assign annotations to both their Helm templated resources and Helm chart dependencies that Helm then uses to generate a deployment sequence at installation time. Three new annotations would be added to enable this desribed next. +At a high level, allow Chart Developers to assign annotations to both their Helm templated resources and Helm chart dependencies that Helm then uses to generate a deployment sequence at installation time. Three new annotations would be added to enable this described next. - `helm.sh/layer`: Declare a layer that a given resource belongs to. Any numebr of resources can belong to a layer. -- `helm.sh/dependson/layer`: Declare a layer that must exist and in a ready state before this resource can be deployed. -- `helm.sh/dependson/chart`: Declare a chart dependency that must exist and in a ready state before this resource can be deployed. +- `helm.sh/depends-on/layer`: Declare a layer that must exist and in a ready state before this resource can be deployed. +- `helm.sh/depends-on/chart`: Declare a chart dependency that must exist and in a ready state before this resource can be deployed. For the chart to be declared ready, all of its resources, with their sequencing order taken into consideration, would need to be deployed and declared ready. A layer would not be considered "ready" and the next layer installed until: - all jobs in the layer are DONE - all other resources in the layer are READY #### Example: -``` +```yaml # resource 1 metadata: name: foo @@ -64,8 +64,8 @@ metadata: In this example, Helm would be responsible for resolving the annotations on these three resources and deploy all resources in the following order: ``` -layer1: [foo] - || +layer1: [foo] + || || [someChartDependency] || || \/ || @@ -75,12 +75,14 @@ layer2: [bar] || layer3: [fizz] ``` +This approach is prone to circular dependencies. During the templating phase, Helm will have logic to detect, and report any circular dependencies found in the chart templates. + ### Proposal 2: Weighted Resouces (without hooks) Expand on the the weight capabilities of hooks, but allow them to be defined outside of the context of hooks for the chart. Add a new annotation `helm.sh/weight` that helm then uses to order when resources are deployed based on the same weighting rules that hooks use today. #### Example: -``` +```yaml # resource 1 metadata: name: foo @@ -102,8 +104,8 @@ metadata: In this example, Helm would be responsible for resolving the annotations on these three resources and deploy all resources in the following order: ``` --2: [foo] - || +-2: [foo] + || \/ -1: [bar] || @@ -111,6 +113,52 @@ In this example, Helm would be responsible for resolving the annotations on thes 0: [fizz] ``` +### Readiness + +In order to enforce sequencing, new `helm.sh/resource-ready` annotation would be used to determine when a resource is ready, allowing helm to proceed deploying the next group of resources, or failing a deployment. Helm would query, using jsonpath syntax, status fields of the annotated resource. Some native kubernetes resources that have stable APIs e.g `v1` resources such as `Pod` and `Deployment`, would have default queries which can be overriden. In Helm cannot determine how to check a resource's readiness when it should, it will do nothing and log this. + +#### Example +```yaml +kind: Job +metadata: + name: barz + annotations: + helm.sh/resource-ready: "status.succeeded==1" +status: + succeeded: 1 +``` + +#### Sequencing order + +Resources with sequencing annotations would be deployed first followed by resources without. If a resource has a `helm.sh/depends-on/chart` annotation, all resources of the referred subchart would be deployed and checked for readiness before deploying the dependant resource. Only resources that Helm can determine readiness for will be checked. Chart authors would need to annotate their chart resources accordingly. + +Helm would scope each subchart layer annotation names using a delimiter such as `.` e.g `mysubchart.mylayer` to avoid any name collisions. This is an internal implementation detail rather than feature chart authors or operators would need to know. + +`helm template` would pring all the resources in the order they would be deployed. The groups would be delimited using a `## Layer: ` comment indicate the beginning of each layer + +```yaml +## Layer: layer1 +# resource 1 +metadata: + name: foo + annotations: + helm.sh/weight: "-2" +--- +# resource 2 +metadata: + name: bar + annotations: + helm.sh/weight: "-1" +--- +## Layer: layer2 +# resource 3 +metadata: + name: fizz + annotations: + helm.sh/weight: 0 + +``` + ## Backwards compatibility Helm will continue to deploy all resources and dependencies at once, as adding the above defined annotations is when the installation behavior would change. @@ -138,4 +186,4 @@ N/A ## References -N/A \ No newline at end of file +N/A From 163c6bf91994e35c2fbdc446ed3346b59fb514e2 Mon Sep 17 00:00:00 2001 From: Evans Mungai Date: Fri, 29 Nov 2024 11:19:21 +0000 Subject: [PATCH 04/13] Rename Annotations and some minor improvements Signed-off-by: Evans Mungai --- hips/hip-00xx-sequencing.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index 66eb423b..387a80a9 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -19,7 +19,7 @@ Additionally, Helm currently doesn't provide a way to sequence when chart depend ## Rationale -### Proposal 1: Annotations +### Proposal 1: Named Dependencies This design was chosen due to simplicity and clarity of how it works for both the Helm developer and Application Operator ### Proposal 2: Weighted Resouces (without hooks) @@ -27,16 +27,14 @@ This design was proposed as an alternative that functions very similarly to hook ## Specification -### Proposal 1: Annotations -At a high level, allow Chart Developers to assign annotations to both their Helm templated resources and Helm chart dependencies that Helm then uses to generate a deployment sequence at installation time. Three new annotations would be added to enable this described next. +### Proposal 1: Named Dependencies +At a high level, allow Chart Developers to assign named dependency annotations to both their Helm templated resources and Helm chart dependencies that Helm then uses to generate a deployment sequence at installation time. Three new annotations would be added to enable this described next. - `helm.sh/layer`: Declare a layer that a given resource belongs to. Any numebr of resources can belong to a layer. - `helm.sh/depends-on/layer`: Declare a layer that must exist and in a ready state before this resource can be deployed. - `helm.sh/depends-on/chart`: Declare a chart dependency that must exist and in a ready state before this resource can be deployed. For the chart to be declared ready, all of its resources, with their sequencing order taken into consideration, would need to be deployed and declared ready. -A layer would not be considered "ready" and the next layer installed until: -- all jobs in the layer are DONE -- all other resources in the layer are READY +A layer would not be considered "ready" and the next layer deployed until all resources in that layer are considered "ready". Readiness is described in a later section. #### Example: ```yaml @@ -51,15 +49,15 @@ metadata: name: bar annotations: helm.sh/layer: layer2 - helm.sh/dependson/layer: layer1 + helm.sh/depends-on/layer: layer1 --- # resource 3 metadata: name: fizz annotations: helm.sh/layer: layer3 - helm.sh/dependson/layer: layer1 - helm.sh/dependson/chart: someChartDependency + helm.sh/depends-on/layer: layer1 + helm.sh/depends-on/chart: someChartDependency ``` In this example, Helm would be responsible for resolving the annotations on these three resources and deploy all resources in the following order: @@ -132,9 +130,9 @@ status: Resources with sequencing annotations would be deployed first followed by resources without. If a resource has a `helm.sh/depends-on/chart` annotation, all resources of the referred subchart would be deployed and checked for readiness before deploying the dependant resource. Only resources that Helm can determine readiness for will be checked. Chart authors would need to annotate their chart resources accordingly. -Helm would scope each subchart layer annotation names using a delimiter such as `.` e.g `mysubchart.mylayer` to avoid any name collisions. This is an internal implementation detail rather than feature chart authors or operators would need to know. +Helm would scope each subchart layer annotation names using a delimiter such as `.` e.g `someChartDependency.mylayer` to avoid any name collisions. This is an internal implementation detail rather than feature chart authors or operators would need to know. -`helm template` would pring all the resources in the order they would be deployed. The groups would be delimited using a `## Layer: ` comment indicate the beginning of each layer +`helm template` would print all resources in the order they would be deployed. Groups of resources in a layer would be delimited using a `## Layer: ` comment indicate the beginning of each layer ```yaml ## Layer: layer1 From a54be4d9cdb7cd30d86f5b1e92fb97c1f5a22e0a Mon Sep 17 00:00:00 2001 From: Evans Mungai Date: Mon, 2 Dec 2024 12:12:48 +0000 Subject: [PATCH 05/13] Add prior open issues to HIP Signed-off-by: Evans Mungai --- hips/hip-00xx-sequencing.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index 387a80a9..7d4063f3 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -182,6 +182,11 @@ N/A - Choose between Proposal 1 and Proposal 2 - Should this featureset take into account allowing Helm Developers to declare custom "readiness" definitions for a given layer, besides the default? -## References +## Prior raised issues + +- https://github.com/helm/helm/pull/12541 +- https://github.com/helm/helm/pull/9534 +- https://github.com/helm/helm/issues/8439 +- https://github.com/helm/community/pull/230 N/A From 9fe061a033e712df9465ffefca49c78ed2613ebf Mon Sep 17 00:00:00 2001 From: Evans Mungai Date: Mon, 2 Dec 2024 12:39:35 +0000 Subject: [PATCH 06/13] A few more changes Signed-off-by: Evans Mungai --- hips/hip-00xx-sequencing.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index 7d4063f3..abfe5fcb 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -9,11 +9,11 @@ status: "draft" ## Abstract -This HIP is to propose a new featureset in Helm 4 to provide Helm developers a well supported way of defining what order chart resources and chart dependencies should be deployed to Kubernetes. +This HIP is to propose a new featureset in Helm 4 to provide Application developers, who create heam charts for their applications, a well supported way of defining what order chart resources and chart dependencies should be deployed to Kubernetes. ## Motivation -Today, to accomplish resource sequencing you have two options. The first is leveraging helm hooks, the second is building required sequencing into the application (via startup code or init containers). The existing hooks and weights can be a tedious to build and maintain for Helm developers, and built-in app sequencing can unecessarily increase complexity of a Helm application that needs to be maintained by Application Developers. Helm as a package manager should be capable of enabling developers to properly sequence how their applications are deployed, and by providing such a mechanism to developers, this will significantly improve the Helm and Application developer experiences. +Today, to accomplish resource sequencing you have two options. The first is leveraging helm hooks, the second is building required sequencing into the application (via startup code or init containers). The existing hooks and weights can be tedious to build and maintain for Application developers, and built-in app sequencing can unecessarily increase complexity of a Helm application that needs to be maintained by Application Developers. Helm as a package manager should be capable of enabling developers to properly sequence how their applications are deployed, and by providing such a mechanism to developers, this will significantly improve the Application developer's experience. Additionally, Helm currently doesn't provide a way to sequence when chart dependencies are deployed, and this featureset would ideally address this. @@ -128,9 +128,9 @@ status: #### Sequencing order -Resources with sequencing annotations would be deployed first followed by resources without. If a resource has a `helm.sh/depends-on/chart` annotation, all resources of the referred subchart would be deployed and checked for readiness before deploying the dependant resource. Only resources that Helm can determine readiness for will be checked. Chart authors would need to annotate their chart resources accordingly. +Resources with sequencing annotations would be deployed first followed by resources without. If a resource has a `helm.sh/depends-on/chart` annotation, all resources of the referred subchart would be deployed and checked for readiness before deploying the dependant resource. Only resources that Helm can determine their readiness for will be checked. Chart authors would need to annotate their chart resources accordingly. Helm will use default readiness checks for subcharts that do have their templates annotated. -Helm would scope each subchart layer annotation names using a delimiter such as `.` e.g `someChartDependency.mylayer` to avoid any name collisions. This is an internal implementation detail rather than feature chart authors or operators would need to know. +Helm would scope each subchart layer annotation names using a delimiter e.g `someChartDependency#mylayer` to avoid any name collisions. This is an internal implementation detail rather than feature chart authors or operators would need to know. `helm template` would print all resources in the order they would be deployed. Groups of resources in a layer would be delimited using a `## Layer: ` comment indicate the beginning of each layer @@ -159,7 +159,7 @@ metadata: ## Backwards compatibility -Helm will continue to deploy all resources and dependencies at once, as adding the above defined annotations is when the installation behavior would change. +Helm will continue to deploy all resources and dependencies at once, as adding the above defined annotations is when the installation behavior would change. If a template in a chart defines `helm.sh/depends-on/chart: someChartDependency` annotation, Helm will wait for the subchart to be ready for all resources with default readiness checks. This will also apply to subcharts that do not have any sequencing annotations. ## Security implications From de97e1ce2bcab5c1da4656b66a3cf5cf3bc7a6d2 Mon Sep 17 00:00:00 2001 From: Evans Mungai Date: Mon, 2 Dec 2024 15:46:31 +0000 Subject: [PATCH 07/13] Add one more wording change Signed-off-by: Evans Mungai --- hips/hip-00xx-sequencing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index abfe5fcb..1684a684 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -180,7 +180,7 @@ N/A ## Open issues - Choose between Proposal 1 and Proposal 2 -- Should this featureset take into account allowing Helm Developers to declare custom "readiness" definitions for a given layer, besides the default? +- Should this featureset take into account allowing Application developers to declare custom "readiness" definitions for given resources, besides the default? ## Prior raised issues From e83cb0aaced15ce164cd76b6e098f421dbec3796 Mon Sep 17 00:00:00 2001 From: Evans Mungai Date: Fri, 6 Dec 2024 18:51:57 +0000 Subject: [PATCH 08/13] Make helm.sh/depends-on/ annotations plural Signed-off-by: Evans Mungai --- hips/hip-00xx-sequencing.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index 1684a684..e7952512 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -9,7 +9,7 @@ status: "draft" ## Abstract -This HIP is to propose a new featureset in Helm 4 to provide Application developers, who create heam charts for their applications, a well supported way of defining what order chart resources and chart dependencies should be deployed to Kubernetes. +This HIP is to propose a new featureset in Helm 4 to provide Application developers, who create helm charts for their applications, a well supported way of defining what order chart resources and chart dependencies should be deployed to Kubernetes. ## Motivation @@ -30,9 +30,9 @@ This design was proposed as an alternative that functions very similarly to hook ### Proposal 1: Named Dependencies At a high level, allow Chart Developers to assign named dependency annotations to both their Helm templated resources and Helm chart dependencies that Helm then uses to generate a deployment sequence at installation time. Three new annotations would be added to enable this described next. -- `helm.sh/layer`: Declare a layer that a given resource belongs to. Any numebr of resources can belong to a layer. -- `helm.sh/depends-on/layer`: Declare a layer that must exist and in a ready state before this resource can be deployed. -- `helm.sh/depends-on/chart`: Declare a chart dependency that must exist and in a ready state before this resource can be deployed. For the chart to be declared ready, all of its resources, with their sequencing order taken into consideration, would need to be deployed and declared ready. +- `helm.sh/layer`: Declare a layer that a given resource belongs to. Any numebr of resources can belong to a layer. A resource can only belong to one layer. +- `helm.sh/depends-on/layers`: Declare layers that must exist and in a ready state before this resource can be deployed. Order of the layers has no significance +- `helm.sh/depends-on/charts`: Declare chart dependencies that must exist and in a ready state before the parent chart can be deployed. For the dependency or subchart chart to be declared ready, all of its resources, with their sequencing order taken into consideration, would need to be deployed and declared ready. Order of the charts has no significance. A layer would not be considered "ready" and the next layer deployed until all resources in that layer are considered "ready". Readiness is described in a later section. @@ -40,24 +40,24 @@ A layer would not be considered "ready" and the next layer deployed until all re ```yaml # resource 1 metadata: - name: foo + name: db-service annotations: - helm.sh/layer: layer1 + helm.sh/layer: database --- # resource 2 metadata: - name: bar + name: app-ingress annotations: - helm.sh/layer: layer2 - helm.sh/depends-on/layer: layer1 + helm.sh/layer: app + helm.sh/depends-on/layers: "database, queue" --- # resource 3 metadata: - name: fizz + name: queue-processor annotations: - helm.sh/layer: layer3 - helm.sh/depends-on/layer: layer1 - helm.sh/depends-on/chart: someChartDependency + helm.sh/layer: queue + helm.sh/depends-on/layers: another-layer + helm.sh/depends-on/charts: "rabbitmq, minio" ``` In this example, Helm would be responsible for resolving the annotations on these three resources and deploy all resources in the following order: @@ -128,7 +128,7 @@ status: #### Sequencing order -Resources with sequencing annotations would be deployed first followed by resources without. If a resource has a `helm.sh/depends-on/chart` annotation, all resources of the referred subchart would be deployed and checked for readiness before deploying the dependant resource. Only resources that Helm can determine their readiness for will be checked. Chart authors would need to annotate their chart resources accordingly. Helm will use default readiness checks for subcharts that do have their templates annotated. +Resources with sequencing annotations would be deployed first followed by resources without. If a resource has a `helm.sh/depends-on/charts` annotation, all resources of the referred subchart would be deployed and checked for readiness before deploying the dependant resource. Only resources that Helm can determine their readiness for will be checked. Chart authors would need to annotate their chart resources accordingly. Helm will use default readiness checks for subcharts that do have their templates annotated. Helm would scope each subchart layer annotation names using a delimiter e.g `someChartDependency#mylayer` to avoid any name collisions. This is an internal implementation detail rather than feature chart authors or operators would need to know. @@ -159,7 +159,7 @@ metadata: ## Backwards compatibility -Helm will continue to deploy all resources and dependencies at once, as adding the above defined annotations is when the installation behavior would change. If a template in a chart defines `helm.sh/depends-on/chart: someChartDependency` annotation, Helm will wait for the subchart to be ready for all resources with default readiness checks. This will also apply to subcharts that do not have any sequencing annotations. +Helm will continue to deploy all resources and dependencies at once, as adding the above defined annotations is when the installation behavior would change. If a template in a chart defines `helm.sh/depends-on/charts: someChartDependency` annotation, Helm will wait for the subchart to be ready for all resources with default readiness checks. This will also apply to subcharts that do not have any sequencing annotations. ## Security implications From 6712256a0ab09af7ac59ff119613b970e3f8fb82 Mon Sep 17 00:00:00 2001 From: Evans Mungai Date: Fri, 6 Dec 2024 18:57:45 +0000 Subject: [PATCH 09/13] Update hips/hip-00xx-sequencing.md Co-authored-by: Scott Rigby Signed-off-by: Evans Mungai --- hips/hip-00xx-sequencing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index e7952512..076f640d 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -113,7 +113,7 @@ In this example, Helm would be responsible for resolving the annotations on thes ### Readiness -In order to enforce sequencing, new `helm.sh/resource-ready` annotation would be used to determine when a resource is ready, allowing helm to proceed deploying the next group of resources, or failing a deployment. Helm would query, using jsonpath syntax, status fields of the annotated resource. Some native kubernetes resources that have stable APIs e.g `v1` resources such as `Pod` and `Deployment`, would have default queries which can be overriden. In Helm cannot determine how to check a resource's readiness when it should, it will do nothing and log this. +In order to enforce sequencing, new `helm.sh/resource-ready` annotation would be used to determine when a resource is ready, allowing helm to proceed deploying the next group of resources, or failing a deployment. Helm would query, using jsonpath syntax, status fields of the annotated resource. Some native kubernetes resources that have stable APIs e.g `v1` resources such as `Pod` and `Deployment`, would have default queries which can be overriden. If Helm cannot determine how to check a resource's readiness when it should, it will do nothing and log this. #### Example ```yaml From 778b4d15b09157e44eef0467d8b37ba7c18fdcdc Mon Sep 17 00:00:00 2001 From: Evans Mungai Date: Fri, 6 Dec 2024 19:30:51 +0000 Subject: [PATCH 10/13] Add --wait/--wait-for-job comment Signed-off-by: Evans Mungai --- hips/hip-00xx-sequencing.md | 1 + 1 file changed, 1 insertion(+) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index 076f640d..334965a6 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -181,6 +181,7 @@ N/A - Choose between Proposal 1 and Proposal 2 - Should this featureset take into account allowing Application developers to declare custom "readiness" definitions for given resources, besides the default? +- How will `--wait` and `--wait-for-jobs` work with sequencing annotations? ## Prior raised issues From 66b3861e83e89dbd8ac24a09a478d2ff5fd1348f Mon Sep 17 00:00:00 2001 From: Joe Beck Date: Tue, 10 Dec 2024 12:00:24 -0800 Subject: [PATCH 11/13] Updates from PR comments. Move proposal 2 to rejected ideas, clarify intentions on how/why this should be built Signed-off-by: Joe Beck --- hips/hip-00xx-sequencing.md | 61 ++++++++----------------------------- 1 file changed, 13 insertions(+), 48 deletions(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index 334965a6..3363bfd9 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -13,28 +13,25 @@ This HIP is to propose a new featureset in Helm 4 to provide Application develop ## Motivation +The driving motivator here is to allow application developers to control what order resources are bundled and sent to the K8s API server, referred to as resource sequencing for the rest of this HIP. + Today, to accomplish resource sequencing you have two options. The first is leveraging helm hooks, the second is building required sequencing into the application (via startup code or init containers). The existing hooks and weights can be tedious to build and maintain for Application developers, and built-in app sequencing can unecessarily increase complexity of a Helm application that needs to be maintained by Application Developers. Helm as a package manager should be capable of enabling developers to properly sequence how their applications are deployed, and by providing such a mechanism to developers, this will significantly improve the Application developer's experience. Additionally, Helm currently doesn't provide a way to sequence when chart dependencies are deployed, and this featureset would ideally address this. ## Rationale -### Proposal 1: Named Dependencies This design was chosen due to simplicity and clarity of how it works for both the Helm developer and Application Operator -### Proposal 2: Weighted Resouces (without hooks) -This design was proposed as an alternative that functions very similarly to hooks today, to provide the same sequencing functionality outside of the scope of hooks. - ## Specification -### Proposal 1: Named Dependencies At a high level, allow Chart Developers to assign named dependency annotations to both their Helm templated resources and Helm chart dependencies that Helm then uses to generate a deployment sequence at installation time. Three new annotations would be added to enable this described next. - `helm.sh/layer`: Declare a layer that a given resource belongs to. Any numebr of resources can belong to a layer. A resource can only belong to one layer. - `helm.sh/depends-on/layers`: Declare layers that must exist and in a ready state before this resource can be deployed. Order of the layers has no significance - `helm.sh/depends-on/charts`: Declare chart dependencies that must exist and in a ready state before the parent chart can be deployed. For the dependency or subchart chart to be declared ready, all of its resources, with their sequencing order taken into consideration, would need to be deployed and declared ready. Order of the charts has no significance. -A layer would not be considered "ready" and the next layer deployed until all resources in that layer are considered "ready". Readiness is described in a later section. +The installation process would group resources in the same layer and send them to the K8s API Server in one bundle, and once all resources are "ready", the next layer would be installed. A layer would not be considered "ready" and the next layer installed until all resources in that layer are considered "ready". Readiness is described in a later section. A similar process would apply for upgrades. Uninstalls would function on the same layer order, but backwards, where a layer is not uninstalled until all layers that depend on it are first uninstalled. #### Example: ```yaml @@ -75,42 +72,6 @@ layer3: [fizz] This approach is prone to circular dependencies. During the templating phase, Helm will have logic to detect, and report any circular dependencies found in the chart templates. -### Proposal 2: Weighted Resouces (without hooks) - -Expand on the the weight capabilities of hooks, but allow them to be defined outside of the context of hooks for the chart. Add a new annotation `helm.sh/weight` that helm then uses to order when resources are deployed based on the same weighting rules that hooks use today. - -#### Example: -```yaml -# resource 1 -metadata: - name: foo - annotations: - helm.sh/weight: "-2" ---- -# resource 2 -metadata: - name: bar - annotations: - helm.sh/weight: "-1" ---- -# resource 3 -metadata: - name: fizz - annotations: - helm.sh/weight: 0 -``` -In this example, Helm would be responsible for resolving the annotations on these three resources and deploy all resources in the following order: - -``` --2: [foo] - || - \/ --1: [bar] - || - \/ -0: [fizz] -``` - ### Readiness In order to enforce sequencing, new `helm.sh/resource-ready` annotation would be used to determine when a resource is ready, allowing helm to proceed deploying the next group of resources, or failing a deployment. Helm would query, using jsonpath syntax, status fields of the annotated resource. Some native kubernetes resources that have stable APIs e.g `v1` resources such as `Pod` and `Deployment`, would have default queries which can be overriden. If Helm cannot determine how to check a resource's readiness when it should, it will do nothing and log this. @@ -140,26 +101,27 @@ Helm would scope each subchart layer annotation names using a delimiter e.g `som metadata: name: foo annotations: - helm.sh/weight: "-2" + helm.sh/layer: layer1 --- # resource 2 metadata: name: bar annotations: - helm.sh/weight: "-1" + helm.sh/layer: layer1 --- ## Layer: layer2 # resource 3 metadata: name: fizz annotations: - helm.sh/weight: 0 + helm.sh/layer: layer2 + helm.sh/depends-on/layers: "layer1" ``` ## Backwards compatibility -Helm will continue to deploy all resources and dependencies at once, as adding the above defined annotations is when the installation behavior would change. If a template in a chart defines `helm.sh/depends-on/charts: someChartDependency` annotation, Helm will wait for the subchart to be ready for all resources with default readiness checks. This will also apply to subcharts that do not have any sequencing annotations. +Helm will continue to install/upgrade/uninstall all resources and dependencies at once, as adding the above defined annotations is when the installation behavior would change. If a template in a chart defines `helm.sh/depends-on/charts: someChartDependency` annotation, Helm will wait for the subchart to be ready for all resources with default readiness checks. This will also apply to subcharts that do not have any sequencing annotations. ## Security implications @@ -175,13 +137,16 @@ N/A ## Rejected ideas -N/A +1. A weight based system, similar to Helm hooks + - Static numbering of the order is more challenging to develop and maintain + - Modifying the order can lead to cascading changes. + - Dynamically named system solves these problems for the application developers. ## Open issues -- Choose between Proposal 1 and Proposal 2 - Should this featureset take into account allowing Application developers to declare custom "readiness" definitions for given resources, besides the default? - How will `--wait` and `--wait-for-jobs` work with sequencing annotations? +- Chart dependencies should be part of the Chart.yaml instead. ## Prior raised issues From c018bbb4e7a746661d046aee5a4bffa457c0592e Mon Sep 17 00:00:00 2001 From: Evans Mungai Date: Fri, 13 Dec 2024 19:35:14 +0000 Subject: [PATCH 12/13] Descibe how to handle subchart dependencies Signed-off-by: Evans Mungai --- hips/hip-00xx-sequencing.md | 98 ++++++++++++++++++++++++++----------- 1 file changed, 69 insertions(+), 29 deletions(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index 3363bfd9..60b7e5fa 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -9,7 +9,8 @@ status: "draft" ## Abstract -This HIP is to propose a new featureset in Helm 4 to provide Application developers, who create helm charts for their applications, a well supported way of defining what order chart resources and chart dependencies should be deployed to Kubernetes. +This HIP is to propose a new featureset in Helm 4 to provide Application developers, who create helm charts for their applications, a well supported way of defining what order chart resources and chart dependencies should be deployed to Kubernetes. Helm deploys all manifests at the same time. This HIP will propose a way for Helm to deploy manifests in batches, and inspect states of these resources to enforce sequencing. + ## Motivation @@ -17,7 +18,7 @@ The driving motivator here is to allow application developers to control what or Today, to accomplish resource sequencing you have two options. The first is leveraging helm hooks, the second is building required sequencing into the application (via startup code or init containers). The existing hooks and weights can be tedious to build and maintain for Application developers, and built-in app sequencing can unecessarily increase complexity of a Helm application that needs to be maintained by Application Developers. Helm as a package manager should be capable of enabling developers to properly sequence how their applications are deployed, and by providing such a mechanism to developers, this will significantly improve the Application developer's experience. -Additionally, Helm currently doesn't provide a way to sequence when chart dependencies are deployed, and this featureset would ideally address this. +Additionally, Helm currently doesn't provide a way to sequence when chart dependencies are deployed and this featureset would ideally address this. ## Rationale @@ -25,15 +26,19 @@ This design was chosen due to simplicity and clarity of how it works for both th ## Specification -At a high level, allow Chart Developers to assign named dependency annotations to both their Helm templated resources and Helm chart dependencies that Helm then uses to generate a deployment sequence at installation time. Three new annotations would be added to enable this described next. +At a high level, allow Chart Developers to assign named dependencies to both their Helm templated resources and Helm chart dependencies that Helm then uses to generate a deployment sequence at installation time. The following annotations would be added to enable this. + +*Additions to templates* +- `helm.sh/layer`: Annotation to declare a layer that a given resource belongs to. Any number of resources can belong to a layer. A resource can only belong to one layer. +- `helm.sh/depends-on/layers`: Annotation to declare layers that must exist and in a ready state before this resource can be deployed. Order of the layers has no significance -- `helm.sh/layer`: Declare a layer that a given resource belongs to. Any numebr of resources can belong to a layer. A resource can only belong to one layer. -- `helm.sh/depends-on/layers`: Declare layers that must exist and in a ready state before this resource can be deployed. Order of the layers has no significance -- `helm.sh/depends-on/charts`: Declare chart dependencies that must exist and in a ready state before the parent chart can be deployed. For the dependency or subchart chart to be declared ready, all of its resources, with their sequencing order taken into consideration, would need to be deployed and declared ready. Order of the charts has no significance. +*Additions to Chart.yaml* +- `helm.sh/depends-on/charts`: Annotation added to `Chart.yaml` to declare chart dependencies, by name or tags, that must be deployed fully and in a ready state before the chart can be deployed. For the dependency or subchart chart to be declared ready, all of its resources, with their sequencing order taken into consideration, would need to be deployed and declared ready. Order of the charts has no significance. +- `depends-on`: A new field added to `Chart.yaml` `dependencies` fields that is meant to declare a list of subcharts, by name or tag, that need to be ready before the subchart in questions get installed. This will be used to create a dependency graph for subcharts. -The installation process would group resources in the same layer and send them to the K8s API Server in one bundle, and once all resources are "ready", the next layer would be installed. A layer would not be considered "ready" and the next layer installed until all resources in that layer are considered "ready". Readiness is described in a later section. A similar process would apply for upgrades. Uninstalls would function on the same layer order, but backwards, where a layer is not uninstalled until all layers that depend on it are first uninstalled. +The installation process would group resources in the same layer and send them to the K8s API Server in one bundle, and once all resources are "ready", the next layer would be installed. A layer would not be considered "ready" and the next layer installed until all resources in that layer are considered "ready". Readiness is described in a later section. A similar process would apply for upgrades. Uninstalls would function on the same layer order, but backwards, where a layer is not uninstalled until all layers that depend on it are first uninstalled. Upgrades would follow the same order as installation. -#### Example: +#### Templates example: ```yaml # resource 1 metadata: @@ -43,7 +48,7 @@ metadata: --- # resource 2 metadata: - name: app-ingress + name: my-app annotations: helm.sh/layer: app helm.sh/depends-on/layers: "database, queue" @@ -56,25 +61,61 @@ metadata: helm.sh/depends-on/layers: another-layer helm.sh/depends-on/charts: "rabbitmq, minio" ``` -In this example, Helm would be responsible for resolving the annotations on these three resources and deploy all resources in the following order: +In this example, Helm would be responsible for resolving the annotations on these three resources and deploy all resources in the following order. Resources in `database` and `queue` layers would be deployed at the same time. They would need to be ready before attempting to deploy `app` layer resources: + +``` +"database" layer: [db-service] + || +"queue" layer: || [queue-processor] + || || + || || + \/ \/ + \\ // + \\ // + \/ \/ +"app" layer: [my-app] +``` + +#### Chart dependencies example + +```yaml +name: foo +annotations: + helm.sh/depends-on/charts: ["bar", "rabbitmq"] +dependencies: + - name: nginx + version: "18.3.1" + repository: "oci://registry-1.docker.io/bitnamicharts" + - name: rabbitmq + version: "9.3.1" + repository: "oci://registry-1.docker.io/bitnamicharts" + - name: bar # This is a subchart packaged with "foo" in charts dir. It's not pulled from a remote location + version: "0.1.0" + depends-on: ["nginx", "rabbitmq"] + condition: bar.enabled +``` ``` -layer1: [foo] - || - || [someChartDependency] - || || - \/ || -layer2: [bar] || - \\ // - \/ \/ -layer3: [fizz] + [nginx] [rabbitmq] + || || + || || + \/ \/ + \\ // + \/ \/ + [bar] + || + || + \/ + [foo] ``` -This approach is prone to circular dependencies. During the templating phase, Helm will have logic to detect, and report any circular dependencies found in the chart templates. +In this example, helm will first install and wait for all resources of `nginx` and `rabbitmq` dependencies to be "ready" before attempting to install `bar` resources. Once all resources of `bar` are "ready" then and only then will `foo` chart resources be installed. `foo` would require `rabbitmq` to be ready but since the subchart resources would have been installed before `bar`, this requirement would have been fulfilled. + +This approach of building a directed acyclic graph (DAG) is prone to circular dependencies. During the templating phase, Helm will have logic to detect, and report any circular dependencies found in the chart templates. ### Readiness -In order to enforce sequencing, new `helm.sh/resource-ready` annotation would be used to determine when a resource is ready, allowing helm to proceed deploying the next group of resources, or failing a deployment. Helm would query, using jsonpath syntax, status fields of the annotated resource. Some native kubernetes resources that have stable APIs e.g `v1` resources such as `Pod` and `Deployment`, would have default queries which can be overriden. If Helm cannot determine how to check a resource's readiness when it should, it will do nothing and log this. +In order to enforce sequencing, a new `helm.sh/resource-ready` annotation would be used to determine when a resource is ready, allowing helm to proceed deploying the next group of resources, or failing a deployment. Helm would query, using jsonpath syntax, status fields of the annotated resource. Some native kubernetes resources that have stable APIs e.g `v1` resources such as `Pod` and `Deployment`, would have default queries which can be overriden. If Helm cannot determine how to check a resource's readiness when it should, it will do nothing and log this. #### Example ```yaml @@ -89,14 +130,12 @@ status: #### Sequencing order -Resources with sequencing annotations would be deployed first followed by resources without. If a resource has a `helm.sh/depends-on/charts` annotation, all resources of the referred subchart would be deployed and checked for readiness before deploying the dependant resource. Only resources that Helm can determine their readiness for will be checked. Chart authors would need to annotate their chart resources accordingly. Helm will use default readiness checks for subcharts that do have their templates annotated. - -Helm would scope each subchart layer annotation names using a delimiter e.g `someChartDependency#mylayer` to avoid any name collisions. This is an internal implementation detail rather than feature chart authors or operators would need to know. +Resources with sequencing annotations would be deployed first followed by resources without. If the chart has a `helm.sh/depends-on/charts` annotation in `Chart.yaml`, all resources of the defined subcharts would be deployed and checked for readiness before deploying the chart. Only resources that Helm can determine their readiness for will be checked. Chart authors would need to annotate their chart resources accordingly. Helm will use default readiness checks for subcharts that do have their templates annotated. -`helm template` would print all resources in the order they would be deployed. Groups of resources in a layer would be delimited using a `## Layer: ` comment indicate the beginning of each layer +`helm template` would print all resources in the order they would be deployed. Groups of resources in a layer would be delimited using a `## START layer: ` comment indicating the beginning of each layer and `END layer: `. ```yaml -## Layer: layer1 +## START layer: foo layer1 # resource 1 metadata: name: foo @@ -108,20 +147,21 @@ metadata: name: bar annotations: helm.sh/layer: layer1 +## END layer: foo layer1 --- -## Layer: layer2 +## START layer: bar layer1 # resource 3 metadata: name: fizz annotations: helm.sh/layer: layer2 helm.sh/depends-on/layers: "layer1" - +## END layer: bar layer2 ``` ## Backwards compatibility -Helm will continue to install/upgrade/uninstall all resources and dependencies at once, as adding the above defined annotations is when the installation behavior would change. If a template in a chart defines `helm.sh/depends-on/charts: someChartDependency` annotation, Helm will wait for the subchart to be ready for all resources with default readiness checks. This will also apply to subcharts that do not have any sequencing annotations. +Helm will continue to install/upgrade/uninstall all resources and dependencies at once, as adding the above defined annotations and depends-on field is when the installation behaviour would change. If a chart defines `helm.sh/depends-on/charts: ["subchart"]` annotation in `Chart.yaml`, Helm will wait for the subchart to be ready for all resources with default readiness checks. This will also apply to older subcharts that do not have any sequencing annotations. ## Security implications From 48347585154a7012b86118ef5570243e166f2f41 Mon Sep 17 00:00:00 2001 From: Evans Mungai Date: Tue, 17 Dec 2024 19:11:43 +0000 Subject: [PATCH 13/13] Rename application developers to application distributors Signed-off-by: Evans Mungai --- hips/hip-00xx-sequencing.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/hips/hip-00xx-sequencing.md b/hips/hip-00xx-sequencing.md index 60b7e5fa..b8244107 100644 --- a/hips/hip-00xx-sequencing.md +++ b/hips/hip-00xx-sequencing.md @@ -9,14 +9,14 @@ status: "draft" ## Abstract -This HIP is to propose a new featureset in Helm 4 to provide Application developers, who create helm charts for their applications, a well supported way of defining what order chart resources and chart dependencies should be deployed to Kubernetes. Helm deploys all manifests at the same time. This HIP will propose a way for Helm to deploy manifests in batches, and inspect states of these resources to enforce sequencing. +This HIP is to propose a new featureset in Helm 4 to provide application distributors, who create helm charts for applications, a well supported way of defining what order chart resources and chart dependencies should be deployed to Kubernetes. Helm deploys all manifests at the same time. This HIP will propose a way for Helm to deploy manifests in batches, and inspect states of these resources to enforce sequencing. ## Motivation -The driving motivator here is to allow application developers to control what order resources are bundled and sent to the K8s API server, referred to as resource sequencing for the rest of this HIP. +The driving motivator here is to allow application distributors to control what order resources are bundled and sent to the K8s API server, referred to as resource sequencing for the rest of this HIP. -Today, to accomplish resource sequencing you have two options. The first is leveraging helm hooks, the second is building required sequencing into the application (via startup code or init containers). The existing hooks and weights can be tedious to build and maintain for Application developers, and built-in app sequencing can unecessarily increase complexity of a Helm application that needs to be maintained by Application Developers. Helm as a package manager should be capable of enabling developers to properly sequence how their applications are deployed, and by providing such a mechanism to developers, this will significantly improve the Application developer's experience. +Today, to accomplish resource sequencing you have two options. The first is leveraging helm hooks, the second is building required sequencing into the application (via startup code or init containers). The existing hooks and weights can be tedious to build and maintain for application distributors, and built-in app sequencing can unecessarily increase complexity of a Helm application that needs to be maintained by application distributors. Helm as a package manager should be capable of enabling application distributors to properly sequence how their chart resources are deployed, and by providing such a mechanism to distributors, this will significantly improve the application distributor's experience. Additionally, Helm currently doesn't provide a way to sequence when chart dependencies are deployed and this featureset would ideally address this. @@ -180,11 +180,11 @@ N/A 1. A weight based system, similar to Helm hooks - Static numbering of the order is more challenging to develop and maintain - Modifying the order can lead to cascading changes. - - Dynamically named system solves these problems for the application developers. + - Dynamically named system solves these problems for the application distributors. ## Open issues -- Should this featureset take into account allowing Application developers to declare custom "readiness" definitions for given resources, besides the default? +- Should this featureset take into account allowing application distributors to declare custom "readiness" definitions for given resources, besides the default? - How will `--wait` and `--wait-for-jobs` work with sequencing annotations? - Chart dependencies should be part of the Chart.yaml instead.