Re: [HIP] helm lock

Home Messages Hashtags Subgroups

#368

Re: [HIP] helm lock

Matt Fisher <matt.fisher@...> #368 > I wasn't aware you could do that. Is it common practice for someone to replace a chart for an in place deployment? A common use case is to migrate from a public chart repository (like one published on ArtifactHub) to an internal chart repository. The workflow is very similar to forking a git repository. A chart can be changed after it is deployed. You can test this out yourself by installing one chart and call `helm upgrade` with another chart. The situation surrounding replacing one chart with an entirely different chart is a side-effect of this behaviour; templates can be removed and replaced at-will during an upgrade. It's important to keep in mind that Helm simply renders the templates, compares the rendered manifests with the previous release, and creates/updates/deletes resources as requested by the user. Matthew Fisher Caffeinated Software Engineer Microsoft Canada toggle quoted message Show quoted text From: Justin Garrison <justinleegarrison@...> Sent: Monday, March 1, 2021 1:02 PM To: Matt Fisher <Matt.Fisher@...> Cc: cncf-helm@... <cncf-helm@...> Subject: Re: [cncf-helm] [HIP] helm lock Thanks for the link to the PR. That seems a bit different than what I had in mind. Those are great questions to include in the proposal. Here's some basic answers and a question for clarification. 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? This is out of scope for locking. Charts should be explicit about what versions of dependencies they need and if a dependency cannot be met the upgrade should fail (same way apt and yum work). If I lock a yum package that requires a specific version of glibc yum will prevent me from upgrading glibc based on explicit version dependencies. How would other tools like Helmfile interact with this feature? How can other tools use this feature? What happens if they don't? Maybe I don't know enough about how Helmfile's work but I thought it called `helm` based on the specification in the file. Native version locking would still prevent upgrades so no changes should be needed to Helmfiles. Where do I find out which packages are marked as "held" or "unheld"? It would be great to have a `list` command like apt and yum but the lock information could also be displayed as part of other helm list commands 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? A lock should be only per deployed chart. In helm 3 those are namespace scoped but you can also have some charts deployed multiple times under different names so a lock should only apply to one of them. This is probably the biggest difference between apt/yum because those work at a machine level but helm can have multiple versions of the same chart installed. 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)? I wasn't aware you could do that. Is it common practice for someone to replace a chart for an in place deployment? I had assumed a chart could not be changed after it was deployed. If people do this and have a lock in place then there are unknown results. I suppose it would be the same if I had 2 repos on linux that both provided an nginx package and they both had different version strings. It would be up to me as an admin to know the difference and lock the correct version. -- Justin Garrison justingarrison.com On Thu, Feb 25, 2021 at 2:23 PM Matt Fisher <Matt.Fisher@...> wrote: 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: 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? How would other tools like Helmfile interact with this feature? How can other tools use this feature? What happens if they don't? Where do I find out which packages are marked as "held" or "unheld"? 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? 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. 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
More All Messages By This Member

View All 5 Messages In Topic

#368

Join {cncf-helm@lists.cncf.io to automatically receive all group messages.

Home Hashtags Subgroups Terms