1. posterid:705694
  2. [HIP] helm lock

Re: [HIP] helm lock

Matt Fisher <matt.fisher@...>
 

Hey Justin!

I like this idea. We've had similar proposals presented for resource update locks like https://github.com/helm/helm/pull/5290, though there were several design flaws preventing that from working in a practical sense. Still, it could be worth reading up on its use cases to see if other cases align with your proposal.

In your proposal, it might be worth answering questions such as:
  1. How would this prevent users from manually editing/updating resources underneath the chart using kubectl, kustomize, etc? Is this considered in-scope or out-of-scope?
  2. How would other tools like Helmfile interact with this feature? How can other tools use this feature? What happens if they don't?
  3. Where do I find out which packages are marked as "held" or "unheld"?
  4. If I lock `nginx-ingress-vX.X.X`, does that apply to only one release, one namespace, or cluster-wide? Can I apply this lock across different scopes?
  5. How does the locking mechanism work? If I lock to kubernetes/nginx-ingress-vX.X.X​​ but I call `helm upgrade my-ingress bitnami/nginx-ingress-vX.X.X`, what happens? What happens if I replace it with a different chart (e.g. apache)?
Hope this helps.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

From: cncf-helm@... <cncf-helm@...> on behalf of Justin Garrison via lists.cncf.io <justinleegarrison=gmail.com@...>
Sent: Wednesday, February 24, 2021 5:21 PM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] [HIP] helm lock
 
I would like to propose a process to "lock" a helm release to a specific version so it is safe from `helm upgrade` and other situations that may cause unintended breaking changes.

There are a variety of ways to prevent breaking users with helm charts. Here are a couple I've investigated but both have limits.
  • Publish charts to different repos. This adds a lot of burden on the publisher to make sure all compatible versions are in a specific repo and users have to switch repos to upgrade.
  • Use deprecation messages to require user action before upgrading.
These methods should still be used if the maintainer wants to make sure user upgrades are safe, but it would also be good for consumers of the chart to not accidentally upgrade charts. There may be cases where a repo has stable and unstable versions. In that case it would be best if the user can "lock" their version to a stable release.

I envision a helm lock could work similar to yum versionlock or apt mark. A user can install a specific version of the chart and then run `helm lock nginx-ingress-vX.X.X` and any additional helm upgrades will ignore versions beyond that version. It may also be desired to allow a user to `helm install $CHART --lock` which will automatically lock to the currently available version or they can specify `--version $VERSION` to request a version.

Ideally this lock would be stored in the release's secret metadata and helm will use it if it is available. Without the metadata `helm upgrade` works the same way as it always has.

Users can also `unlock` their releases and locks could appear in helm list or other places metadata about a release is surfaced.

Please let me know what you think so I can write up a HIP if this feature would benefit the community. If there is prior discussion about this I would also be interested in reading it.

--
Justin Garrison
justingarrison.com
Join {cncf-helm@lists.cncf.io to automatically receive all group messages.