Skip to content
Permalink

Comparing changes

This is a direct comparison between two commits made in this repository or its related repositories. View the default comparison for this range or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: helm/community
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: eb8ecef1de1b7372f19f37e3c7e5562b4035c129
Choose a base ref
..
head repository: helm/community
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 2b5d9d7adfe076e11088283fcf52ee0374b8be5d
Choose a head ref
Showing with 4 additions and 7 deletions.
  1. +4 −7 hips/hip-XXXX.md
11 changes: 4 additions & 7 deletions hips/hip-XXXX.md
View file
Original file line number Diff line number Diff line change
@@ -55,17 +55,14 @@ The two main reasons inferred from [HIP-0011](./hip-0011.md) that Helm is conser
And removing the CRDs for those will remove the CR and may cause data loss

For 1., it is thought that Helm should not treat CRDs specially here.
Helm will readily operate on many other cluster wide resources today.
Cluster roles, priority classes, namespaces, etc.
Helm will readily operate on many other cluster wide resources today: Cluster roles, priority classes, namespaces, etc.
That the modification/removal of could easily cause breakage outside of the chart's release.

And in general, Helm should not try and protect uses against unintended functional changes from a chart.
As validating functional changes is well beyond the scope of a package manager.
Helm should treat CRDs the same as other (cluster-wide) resources, where a Helm chart upgrade that causes unintended functional effects should be reverted (rolled back).
In general, Helm as a package manager should not try to prempt unintended functional changes from a chart.
Validating functional changes is well beyond the scope of a package manager.
Helm should treat CRDs the same as other (cluster-wide) resources, where a Helm chart upgrade that causes unintended functional effects should be reverted (rolled back) by the user (chart operator).
And as long as that rollback path exists, this is a suitable path for users to mitigate breaking functional changes.

For the purposes of this HIP, it is though that Helm may modify CRDs, as long as the change is functionally reversable to the operator (via rollback).

For 2., Data loss should be treated more carefully.
As data loss can be irrevocable or require significant effort to restore.
And especially, an application/chart operator should not expect a chart upgrade to cause data loss.