From 82b28b66a1f9b6d878b82f4ccfdec6252a1d14ef Mon Sep 17 00:00:00 2001 From: George Jenkins Date: Wed, 9 Aug 2023 22:00:36 -0700 Subject: [PATCH 1/4] HIP: Server-Side Apply Signed-off-by: George Jenkins --- hips/hip-00XX.md | 161 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 hips/hip-00XX.md diff --git a/hips/hip-00XX.md b/hips/hip-00XX.md new file mode 100644 index 00000000..28dc73d5 --- /dev/null +++ b/hips/hip-00XX.md @@ -0,0 +1,161 @@ +--- +hip: 9999 +title: "Utilize Server Side Apply for installs/upgrades" +authors: [ "George Jenkins " ] +created: "2023-07-07" +type: "feature" +status: "draft" +--- + +## Abstract + + +This HIP proposes for Helm to support Kubernetes' [Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) (SSA) for [object](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-object) management. + +Helm 3 introduced the [three-way strategic merge and patch](https://helm.sh/docs/faq/changes_since_helm2/#improved-upgrade-strategy-3-way-strategic-merge-patches). Allowing Helm to update objects which have been modified by other processes. Kubernetes now offers a similar server-side process that has several advantages over the client-side apply (CSA) methods that Helm and kubectl (for example) have traditionally utilized. + +The scope of this HIP is limited to incorporating SSA as an opt-in feature only. Deferring changing user's existing usage of the (client-side) three-way strategic merge patch processes (without opt-in). And considers how to deal with field conflicts and other compatibility concerns that may arise with the differences between SSA and CSA. + +## Motivation + + + +The primary motivation for Helm to switch to Server-Side Apply is to gain the benefits of Kubernetes managing object upgrades. Where objects may have been modified by another process. The following describes the advantages of SSA from Kubernetes perspective, where SSA generally is considered to be superior: + +https://kubernetes.io/blog/2022/10/20/advanced-server-side-apply/ + +Helm supporting SSA will allow users to realize the benefits of SSA. And longer term goals (out of scope for this HIP) might be for Helm to utilize SSA by default ([similar to kubectl](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3805-ssa-default)). Finally later as a code maintenance benefit, eventually drop support for the strategic-merge patch client-side apply process/code. + +## Rationale + + + +Due to the backwards compatibility concerns documented below, the decision was made to provide opt-in support only. And even when a chart is deployed with SSA enabled, Helm should maintain full compatibility with reverting back to using CSA for upgrades/rollbacks. Additionally it was desirable to mimic kubectl's cli interface/flags. As a way for Helm to be consistent with an existing kubectl functionality. + +## Specification + + + +### General + +Helm will add a new flag to the install, upgrade and rollback sub-commands (modelled after the like `kubectl` flag). And add a corresponding field to the respective install/upgrade/rollback SDK API objects: + +`--server-side=false|true|auto` + +Helm will default to `false` for installs, retaining its existing CSA behavior. And `auto` for upgrade and rollbacks, where Helm will enable SSA based on the whether SSA was utilized for the prior release. With the usage of SSA for a given release being stored in the release's metadata. When enabled, Helm will submit object to the Kubernetes API server via SSA patches. + +If a user deploys a chart with a new version of Helm with SSA enabled, then upgrades the chart with an older version of Helm. It is expected that the older Helm will be able to upgrade the chart with CSA. And the new release's metadata will omit the indication of SSA usage (and so further upgrades/rollbacks will continue to use CSA by default). + +In a future version of Helm 3 cli, it might be desirable to omit a warning if a user is not using SSA (in order to prompt the user to enabling SSA). + +#### Custom resources + +Helm will utilize SSA for custom resources, which it previously [didn't merge](https://github.com/helm/helm/blob/1b260d0a796882a1e90f0fa3c832659dbe2e675c/pkg/kube/converter.go#L54-L69). As SSA allows custom resources to be correctly merged based on metadata within the CRD. Or the API server will use the default approach (). + +#### Conflicts and forcing + +It is possible that when Helm upgrades a chart, there will be a field conflict with another field manager. In this case, Helm should report the error to the user. + +Helm will also add a new flag `--force-conflicts` to the `upgrade` and `rollback` commands (and corresponding API object field). Which will tell the apply to ignore/override field conflicts (and so thus make Helm the field manager). + +(Of note, Helm upgrade already includes the `--force` flag, which tells Helm to replace objects during upgrade. However, given this different semantics of `--force`, it is thought a new flag is required) + +An additional special case is rollbacks on failed upgrade (`--atomic` flag). It is possible for Helm to attempt to rollback to a version which now has a conflict. For which the rollback will fail. Since rollbacks are "best effort" and can fail for other reasons as well, it seems best to treat this new rollback failure-case similarly (report to the user via logging and error). If the user specified `--force-conflicts` to the upgrade, the corresponding rollback should similarly force conflicts (this is the behavior of `--force`). If the rollback is to a release version which previously didn't have SSA enabled, the rollback install should also disable SSA. + +##### [Optional] Transferring ownership + +_this section is optional, and/or for HIP discussion_ + +Helm could also allow acceptance of conflicts and ownership transfer of fields. Similar to the `kubectl` example: https://kubernetes.io/docs/reference/using-api/server-side-apply/#transferring-ownership + +For Helm, options include: + +0. Do nothing: (initially) Given the unknowns of how conflicts will affect users in practice, and the potential complexity of implementing one of the below options. Defer implementing anything until feedback from users can be gathered +1. Chart objects could be annotated with a special annotation: e.g. `helm.sh/accept-conflicts: true`. Helm would apply objects with a distinct field manager name (allowing multiple yaml documents for the same object), and ignore conflicts for the given apply +2. A cli flag (and corresponding API field): `--accept-conflicts-from=`. In this case, Helm would simply accept conflicts from the respectively named field manager (TODO: does client-go / Kubernetes API even easily allow this; how would the users intended changes actually get applied) +3. Allow the releases operator to specify "patches" to a chart + +Dissimilar to `kubectl`, is Helm's distinguishes between Chart developers and Chart operators. Chart developers may not consider, or may not even know, which fields may be overwritten (managed by) by another process in a user's Kubernetes cluster. + +As such, while option 1. is probably the cleanest from an implementation and user understanding perspective. It may have limitations from a operational perspective. Option 2. may not even be technically possible (it is included as a thought on how to give the Chart's operator control). And 3. introduces significant complexity for the operator of the chart (and perhaps Helm). + +#### Special + +- `--dry-run=client` won't work with SSA enabled +- If the user attempts to use SSA with a cluster which does not support it (unlikely: SSA [went GA](https://kubernetes.io/blog/2021/08/06/server-side-apply-ga/) in Kubernetes v1.22), Helm should error. +- Client-side API object validation isn't applicable when SSA enabled (`helm install|upgrade --disable-openapi-validation`) +- Hooks could be deployed with SSA. But as hook objects are not updated (create/delete only), they are not really affected +- Stored release manifests should not change (they store the object as Helm intends) + +### Implementation + +Helm will send object's manifests to the Kubernetes API server via SSA patches. Similar to `kubectl`. Utilizing the field manager name `"helm"`: + +https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L248 +https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L564-L602 + +## Backwards compatibility + + + +There are thought to be four main compatibility concerns for Helm switching to SSA: +1. The differences between object's manifests managed with SSA vs the existing three-way strategic merge process: + - Arrays will be merged + - Removal of unset fields + - Default values +2. Issues with a user enabling/disabling SSA over the lifetime of a release e.g. environment differences or older Helm clients which don't understand SSA +3. SSA will apply to custom resources + +For 1., this HIP limits Helm to opt-in to server side apply, allowing users to verify SSA's behavior matches their expectations. For 2., the user can mitigate by ensuring SSA is consistently used within their environment. But the expectation is that SSA should generally produce equivalent Kubernetes objects as CSA. + +Additionally as noted, SSA isn't compatible with very old Kubernetes versions (Kubernetes v1.17 and prior) + +## Security implications + + + +There should not be any additional security concerns. Server-side apply and client-side apply should be equivalent security-wise. + +## How to teach this + + + +Documentation for how Helm does object upgrades, and the advantages of SSA. Also documentation for the `--server-side=false|true|auto` and `--force-conflicts=false|true` flags, and the defaults for install/upgrades/rollbacks. And the corresponding documentation for the field(s) SDK API objects. + +## Reference implementation + + + +Kubectl: \ + + + +Prototype (hack) for Helm: \ + + + +## Rejected ideas + + + +- Opting users into SSA as default (defer to later) +- Requiring upgrades to be follow install time CSA or SSA setting: users may an old Helm versions. Or may want to "upgrade" an existing release with SSA. + +## Open issues + + + +- How to best allow Helm/users to deal with conflicts (Transferring Ownership) + +## References + + + +- +- +- +- +- \ No newline at end of file From 296269b25917b74e7b3dbbe70ccc09d6b89ef889 Mon Sep 17 00:00:00 2001 From: George Jenkins Date: Thu, 26 Dec 2024 18:06:17 -0800 Subject: [PATCH 2/4] Helm 4 updates Signed-off-by: George Jenkins --- hips/hip-00XX.md | 145 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 101 insertions(+), 44 deletions(-) diff --git a/hips/hip-00XX.md b/hips/hip-00XX.md index 28dc73d5..693896a8 100644 --- a/hips/hip-00XX.md +++ b/hips/hip-00XX.md @@ -5,6 +5,7 @@ authors: [ "George Jenkins " ] created: "2023-07-07" type: "feature" status: "draft" +helm-version: "4" --- ## Abstract @@ -12,26 +13,43 @@ status: "draft" This HIP proposes for Helm to support Kubernetes' [Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) (SSA) for [object](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-object) management. -Helm 3 introduced the [three-way strategic merge and patch](https://helm.sh/docs/faq/changes_since_helm2/#improved-upgrade-strategy-3-way-strategic-merge-patches). Allowing Helm to update objects which have been modified by other processes. Kubernetes now offers a similar server-side process that has several advantages over the client-side apply (CSA) methods that Helm and kubectl (for example) have traditionally utilized. +Helm 3 introduced the [three-way strategic merge and patch](https://helm.sh/docs/faq/changes_since_helm2/#improved-upgrade-strategy-3-way-strategic-merge-patches). +Allowing Helm to update objects which have been modified by other processes. +Kubernetes now offers a similar server-side process that has several advantages over the client-side apply (CSA) methods that Helm and kubectl (for example) have traditionally utilized. + ## Motivation -The primary motivation for Helm to switch to Server-Side Apply is to gain the benefits of Kubernetes managing object upgrades. Where objects may have been modified by another process. The following describes the advantages of SSA from Kubernetes perspective, where SSA generally is considered to be superior: +The primary motivation for Helm to switch to Server-Side Apply is to gain the benefits of Kubernetes server-side management of object upgrades. +The following describes the advantages of SSA from Kubernetes perspective, where SSA generally is considered to be superior: https://kubernetes.io/blog/2022/10/20/advanced-server-side-apply/ -Helm supporting SSA will allow users to realize the benefits of SSA. And longer term goals (out of scope for this HIP) might be for Helm to utilize SSA by default ([similar to kubectl](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3805-ssa-default)). Finally later as a code maintenance benefit, eventually drop support for the strategic-merge patch client-side apply process/code. +Helm supporting SSA will allow Helm users to realize the benefits of SSA. +With Helm 4 utilizing SSA by default ([similar to kubectl](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3805-ssa-default)). + +From a code maintenance benefit, Helm could eventually drop support for the strategic-merge patch CSA implementation/code. ## Rationale -Due to the backwards compatibility concerns documented below, the decision was made to provide opt-in support only. And even when a chart is deployed with SSA enabled, Helm should maintain full compatibility with reverting back to using CSA for upgrades/rollbacks. Additionally it was desirable to mimic kubectl's cli interface/flags. As a way for Helm to be consistent with an existing kubectl functionality. +With Helm 4, it was decided to opt-in to Helm utilizing SSA by default. +Allowing chart operators to gain the benefit of SSA without needing to know about the mechanism. +If during Helm 4 release candidate field usage, SSA as default is deemed to be unsuitable, Helm will revert to utilizing CSA by default. + +A CLI flag will allow users to override SSA opt-in (revert to utilizing CSA), should a chart operator need to for a particular circumstance. + +A chart release mechanism will allow Helm to track and follow SSA enablement for a given release. Tracking SSA enablement will allow Helm to automatically follow SSA enablement for a given release, and in revert to CSA (or SSA) during rollback if that prior release utilized CSA (or SSA). + +Additionally it was desirable to mimic `kubectl`'s CLI interface/flags. +As a way for Helm to be consistent with an existing `kubectl` functionality. ## Specification @@ -39,58 +57,68 @@ Due to the backwards compatibility concerns documented below, the decision was m ### General -Helm will add a new flag to the install, upgrade and rollback sub-commands (modelled after the like `kubectl` flag). And add a corresponding field to the respective install/upgrade/rollback SDK API objects: +Helm will add a new flag to the install, upgrade and rollback commands (modeled after the like `kubectl apply` flag). +And add a corresponding field to the respective install/upgrade/rollback SDK API objects: `--server-side=false|true|auto` -Helm will default to `false` for installs, retaining its existing CSA behavior. And `auto` for upgrade and rollbacks, where Helm will enable SSA based on the whether SSA was utilized for the prior release. With the usage of SSA for a given release being stored in the release's metadata. When enabled, Helm will submit object to the Kubernetes API server via SSA patches. +Helm will default to `true` for installs, enabling SSA. +And `auto` for upgrade and rollbacks, where Helm will enable SSA based on the whether SSA was utilized for the prior release (see below). +When enabled, Helm will submit object to the Kubernetes API server via SSA patches. + +If SSA is utilized for a release, this will be stored as a field in the release's metadata. +If the field is unset when reading a prior release, this implies that the release was created with an old version of Helm utilizing CSA. + +``` +type Release struct { + ApplyMethod *string `json:"apply_method,omitempty"` // "ssa" OR "csa" +} +``` If a user deploys a chart with a new version of Helm with SSA enabled, then upgrades the chart with an older version of Helm. It is expected that the older Helm will be able to upgrade the chart with CSA. And the new release's metadata will omit the indication of SSA usage (and so further upgrades/rollbacks will continue to use CSA by default). -In a future version of Helm 3 cli, it might be desirable to omit a warning if a user is not using SSA (in order to prompt the user to enabling SSA). +In a future version of Helm 4 CLI, it might be desirable to omit a warning if a user is not using SSA (in order to prompt the user to enabling SSA for further releases). #### Custom resources -Helm will utilize SSA for custom resources, which it previously [didn't merge](https://github.com/helm/helm/blob/1b260d0a796882a1e90f0fa3c832659dbe2e675c/pkg/kube/converter.go#L54-L69). As SSA allows custom resources to be correctly merged based on metadata within the CRD. Or the API server will use the default approach (). +Helm will utilize SSA for custom resources, which it previously [didn't merge](https://github.com/helm/helm/blob/1b260d0a796882a1e90f0fa3c832659dbe2e675c/pkg/kube/converter.go#L54-L69). +As SSA allows custom resources to be correctly merged based on metadata within the CRD. +Or the API server will use the default approach (). #### Conflicts and forcing -It is possible that when Helm upgrades a chart, there will be a field conflict with another field manager. In this case, Helm should report the error to the user. - -Helm will also add a new flag `--force-conflicts` to the `upgrade` and `rollback` commands (and corresponding API object field). Which will tell the apply to ignore/override field conflicts (and so thus make Helm the field manager). - -(Of note, Helm upgrade already includes the `--force` flag, which tells Helm to replace objects during upgrade. However, given this different semantics of `--force`, it is thought a new flag is required) - -An additional special case is rollbacks on failed upgrade (`--atomic` flag). It is possible for Helm to attempt to rollback to a version which now has a conflict. For which the rollback will fail. Since rollbacks are "best effort" and can fail for other reasons as well, it seems best to treat this new rollback failure-case similarly (report to the user via logging and error). If the user specified `--force-conflicts` to the upgrade, the corresponding rollback should similarly force conflicts (this is the behavior of `--force`). If the rollback is to a release version which previously didn't have SSA enabled, the rollback install should also disable SSA. - -##### [Optional] Transferring ownership - -_this section is optional, and/or for HIP discussion_ +It is possible that when Helm upgrades (or rollbacks) a chart, there will be a field conflict with another field manager. +In this case, Helm will report the error for the conflict field(s) to the user. -Helm could also allow acceptance of conflicts and ownership transfer of fields. Similar to the `kubectl` example: https://kubernetes.io/docs/reference/using-api/server-side-apply/#transferring-ownership +Helm will also add a new flag `--force-conflicts=false|true` to the install, upgrade and rollback commands (modeled after the life `kubectl apply` flag) +And corresponding API objects field. +When `true` (default `false`), Helm will enabling override the field conflicts, setting field(s) to the charts values. +And also make Helm the field manager for the conflicting field(s). +The `--force-conflicts` flag documentation should explicity mention the downsides of conflict forcing ie. the chart update is overriding object values that another process is expecting to own/manage. -For Helm, options include: +For more details, see the _Overwrite value, become sole manager_ of -0. Do nothing: (initially) Given the unknowns of how conflicts will affect users in practice, and the potential complexity of implementing one of the below options. Defer implementing anything until feedback from users can be gathered -1. Chart objects could be annotated with a special annotation: e.g. `helm.sh/accept-conflicts: true`. Helm would apply objects with a distinct field manager name (allowing multiple yaml documents for the same object), and ignore conflicts for the given apply -2. A cli flag (and corresponding API field): `--accept-conflicts-from=`. In this case, Helm would simply accept conflicts from the respectively named field manager (TODO: does client-go / Kubernetes API even easily allow this; how would the users intended changes actually get applied) -3. Allow the releases operator to specify "patches" to a chart +(Of note, Helm upgrade already includes the `--force` flag, which tells Helm to replace objects during upgrade. +However, given this different semantics of `--force`, a new flag is required) -Dissimilar to `kubectl`, is Helm's distinguishes between Chart developers and Chart operators. Chart developers may not consider, or may not even know, which fields may be overwritten (managed by) by another process in a user's Kubernetes cluster. - -As such, while option 1. is probably the cleanest from an implementation and user understanding perspective. It may have limitations from a operational perspective. Option 2. may not even be technically possible (it is included as a thought on how to give the Chart's operator control). And 3. introduces significant complexity for the operator of the chart (and perhaps Helm). +An additional special case is rollbacks on failed upgrade (`--atomic` flag). It is possible for Helm to attempt to rollback to a version which now has a conflict. +For which the rollback will fail. +Since rollbacks are "best effort" and can fail for other reasons as well, it seems best to treat this new rollback failure-case similarly (report to the user via logging and error). +If the user specified `--force-conflicts` to the upgrade, the corresponding rollback should similarly force conflicts (this is the behavior of `--force`). +If the rollback is to a release version which previously didn't have SSA enabled, the rollback install should also disable SSA. #### Special - `--dry-run=client` won't work with SSA enabled -- If the user attempts to use SSA with a cluster which does not support it (unlikely: SSA [went GA](https://kubernetes.io/blog/2021/08/06/server-side-apply-ga/) in Kubernetes v1.22), Helm should error. +- If the user attempts to use SSA with a cluster which does not support it (unlikely: SSA [went GA](https://kubernetes.io/blog/2021/08/06/server-side-apply-ga/) in Kubernetes v1.22), Helm should error - Client-side API object validation isn't applicable when SSA enabled (`helm install|upgrade --disable-openapi-validation`) - Hooks could be deployed with SSA. But as hook objects are not updated (create/delete only), they are not really affected - Stored release manifests should not change (they store the object as Helm intends) ### Implementation -Helm will send object's manifests to the Kubernetes API server via SSA patches. Similar to `kubectl`. Utilizing the field manager name `"helm"`: +Helm will send object's manifests to the Kubernetes API server via SSA patches. Similar to `kubectl apply`. +Utilizing the field manager name `"helm"`: https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L248 https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L564-L602 @@ -99,15 +127,23 @@ https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2 -There are thought to be four main compatibility concerns for Helm switching to SSA: +SSA should be generally compatible functionality-wide with CSA. +The expectation is that SSA should generally produce equivalent Kubernetes objects as CSA. + +There four main behavioural differences for Helm switching to SSA: + 1. The differences between object's manifests managed with SSA vs the existing three-way strategic merge process: - Arrays will be merged - Removal of unset fields - Default values 2. Issues with a user enabling/disabling SSA over the lifetime of a release e.g. environment differences or older Helm clients which don't understand SSA 3. SSA will apply to custom resources +4. Field management ownership conflicts -For 1., this HIP limits Helm to opt-in to server side apply, allowing users to verify SSA's behavior matches their expectations. For 2., the user can mitigate by ensuring SSA is consistently used within their environment. But the expectation is that SSA should generally produce equivalent Kubernetes objects as CSA. +For 1., chart-operators may opt-out out of SSA. +For 2., the user can control by ensuring SSA is consistently used within their environment. +For 3., the it is generally considered a limitation of Helm not updating custom resources, for which SSA is expected to be an improvement. +For 4., the `--force-conflicts` flag exists. Additionally as noted, SSA isn't compatible with very old Kubernetes versions (Kubernetes v1.17 and prior) @@ -115,25 +151,28 @@ Additionally as noted, SSA isn't compatible with very old Kubernetes versions (K -There should not be any additional security concerns. Server-side apply and client-side apply should be equivalent security-wise. +There should not be any additional security concerns. +Server-side apply and client-side apply should be equivalent security-wise. ## How to teach this -Documentation for how Helm does object upgrades, and the advantages of SSA. Also documentation for the `--server-side=false|true|auto` and `--force-conflicts=false|true` flags, and the defaults for install/upgrades/rollbacks. And the corresponding documentation for the field(s) SDK API objects. +Documentation for how Helm does object upgrades, and the advantages of SSA. +Also documentation for the `--server-side=false|true|auto` and `--force-conflicts=false|true` flags, and the defaults for install/upgrades/rollbacks. +And the corresponding documentation for the field(s) SDK API objects. ## Reference implementation -Kubectl: \ - - +Kubectl: +- +- -Prototype (hack) for Helm: \ - +Prototype (hack) for Helm: +- ## Rejected ideas @@ -141,15 +180,32 @@ Prototype (hack) for Helm: \ -- Opting users into SSA as default (defer to later) -- Requiring upgrades to be follow install time CSA or SSA setting: users may an old Helm versions. Or may want to "upgrade" an existing release with SSA. +### Chart field manager support + +This HIP defers including field manager support in charts. +Helm could enabling apply objects with a distinct field manager names. +e.g. allowing a chart to supply multiple yaml manifest documents for the same object. + +It is unclear how Helm users will interact with such a feature e.g. the chart developer might want/need to specify the objects field manage name in a chart. +And `helm template` might somehow need to allow describing the object's field manager name in its output. + +Once more information is gathered on how chart developers might utilze explicit field manager support, a proposal introducing field manage support for charts could be written. + +### Field ownership transfer + +Helm won't support ownership transfer of fields. +Similar to the `kubectl` example: . + +Dissimilar to `kubectl`, is Helm's distinguishes between chart developers and chart operators. +Chart developers may not consider, or may not even know, which fields may be overwritten (managed by) by another process in a user's Kubernetes cluster. + +Ownership transfer would likley first require charts have field manager support. +As well as additional support for per-object conflicts resolution. ## Open issues -- How to best allow Helm/users to deal with conflicts (Transferring Ownership) - ## References @@ -158,4 +214,5 @@ ultimately pursued. --> - - - -- \ No newline at end of file +- +- \ No newline at end of file From 6759f8274be25019d7e6d256aa3bf83b0325611d Mon Sep 17 00:00:00 2001 From: George Jenkins Date: Thu, 26 Dec 2024 18:14:45 -0800 Subject: [PATCH 3/4] more tidyup Signed-off-by: George Jenkins --- hips/hip-00XX.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/hips/hip-00XX.md b/hips/hip-00XX.md index 693896a8..e476ec63 100644 --- a/hips/hip-00XX.md +++ b/hips/hip-00XX.md @@ -15,7 +15,7 @@ This HIP proposes for Helm to support Kubernetes' [Server-Side Apply](https://ku Helm 3 introduced the [three-way strategic merge and patch](https://helm.sh/docs/faq/changes_since_helm2/#improved-upgrade-strategy-3-way-strategic-merge-patches). Allowing Helm to update objects which have been modified by other processes. -Kubernetes now offers a similar server-side process that has several advantages over the client-side apply (CSA) methods that Helm and kubectl (for example) have traditionally utilized. +Kubernetes now offers a similar server-side process that has several advantages over the client-side apply (CSA) methods that Helm and `kubectl` (for example) have traditionally utilized. -The primary motivation for Helm to switch to Server-Side Apply is to gain the benefits of Kubernetes server-side management of object upgrades. +Switching to SSA allows Helm users (chart operators) is to gain the benefits of Kubernetes server-side field management for object updates. The following describes the advantages of SSA from Kubernetes perspective, where SSA generally is considered to be superior: https://kubernetes.io/blog/2022/10/20/advanced-server-side-apply/ @@ -41,15 +41,16 @@ From a code maintenance benefit, Helm could eventually drop support for the stra With Helm 4, it was decided to opt-in to Helm utilizing SSA by default. -Allowing chart operators to gain the benefit of SSA without needing to know about the mechanism. -If during Helm 4 release candidate field usage, SSA as default is deemed to be unsuitable, Helm will revert to utilizing CSA by default. +Allowing chart operators to gain the benefit of SSA without needing to know about the server-side vs. client-side mechanisms. +If during Helm 4 release candidate field usage, SSA as default is deemed to be unresolvably problematic, Helm 4 will revert to utilizing CSA by default. -A CLI flag will allow users to override SSA opt-in (revert to utilizing CSA), should a chart operator need to for a particular circumstance. +A CLI flag will allow users to override SSA opt-in and revert to utilizing CSA. Should a chart operator need for a particular circumstance. -A chart release mechanism will allow Helm to track and follow SSA enablement for a given release. Tracking SSA enablement will allow Helm to automatically follow SSA enablement for a given release, and in revert to CSA (or SSA) during rollback if that prior release utilized CSA (or SSA). +A chart release mechanism will allow Helm to track and follow SSA enablement for a given release. +Tracking SSA enablement will allow Helm to automatically follow SSA enablement for a given release, and in particular revert to CSA (or SSA) during rollbacks if that prior release utilized CSA (or SSA). Additionally it was desirable to mimic `kubectl`'s CLI interface/flags. -As a way for Helm to be consistent with an existing `kubectl` functionality. +As a way for Helm to be consistent with an existing `kubectl` functionality that Kubernetes users may be familar with. ## Specification @@ -57,21 +58,19 @@ As a way for Helm to be consistent with an existing `kubectl` functionality. ### General -Helm will add a new flag to the install, upgrade and rollback commands (modeled after the like `kubectl apply` flag). -And add a corresponding field to the respective install/upgrade/rollback SDK API objects: - -`--server-side=false|true|auto` +Helm will add a new `--server-side=false|true|auto` flag to the install, upgrade and rollback commands (modeled after the like `kubectl apply` flag). +And add a corresponding field to the respective install/upgrade/rollback SDK API objects. Helm will default to `true` for installs, enabling SSA. And `auto` for upgrade and rollbacks, where Helm will enable SSA based on the whether SSA was utilized for the prior release (see below). When enabled, Helm will submit object to the Kubernetes API server via SSA patches. -If SSA is utilized for a release, this will be stored as a field in the release's metadata. +If SSA or CSA is utilized for a release, this will be stored as a field in the release's metadata. If the field is unset when reading a prior release, this implies that the release was created with an old version of Helm utilizing CSA. ``` type Release struct { - ApplyMethod *string `json:"apply_method,omitempty"` // "ssa" OR "csa" + ApplyMethod *string `json:"apply_method,omitempty"` // "ssa" | "csa" } ``` From 64a36d143d251a3ecaa211993ea53743699d1b71 Mon Sep 17 00:00:00 2001 From: George Jenkins Date: Thu, 26 Dec 2024 18:16:09 -0800 Subject: [PATCH 4/4] more tidyup Signed-off-by: George Jenkins --- hips/hip-00XX.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/hips/hip-00XX.md b/hips/hip-00XX.md index e476ec63..50578736 100644 --- a/hips/hip-00XX.md +++ b/hips/hip-00XX.md @@ -17,10 +17,6 @@ Helm 3 introduced the [three-way strategic merge and patch](https://helm.sh/docs Allowing Helm to update objects which have been modified by other processes. Kubernetes now offers a similar server-side process that has several advantages over the client-side apply (CSA) methods that Helm and `kubectl` (for example) have traditionally utilized. - - ## Motivation