|
Just out of curiosity does anyone know how helm would behave if we used ValidatingAdmissionController webhook to deny the helm release to be modified ? I bet you could rough it out with OPA/Gatekeeper to say “do not allow modifications
to secrets with the helm labels and a lock annotation. I would imagine Helm would error out before upgrading the chart, which would give us close to the locking functionality without even touching helm yet.
If we could confirm that behavior, then we could even look at getting Helm to understand a webhook denial to give a better looking error, and then maybe write a helm plugin to perform the lock/unlock (add/remove the annotation), plus maybe
write a targeting helm release locker webhook, or publish the rego required for OPA.
toggle quoted messageShow quoted text
From: cncf-helm@... <cncf-helm@...>
On Behalf Of Matt Fisher via lists.cncf.io
Sent: Tuesday, March 2, 2021 10:53 AM
To: Justin Garrison <justinleegarrison@...>
Cc: cncf-helm@...
Subject: Re: [cncf-helm] [HIP] helm lock
> 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
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.
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)?
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAIMAAAAdCAYAAACJ8d9VAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAA/ESURBVGhD7VoLlF1Ved57n32ed2Yyk8lzkhCYmLBGU0YSI2BajTQgjTWlVnHASDWCoCwbTQuhATINGslaVKCgGJdUAYtdq6wCwRXRKC5ilQA1JFMC4bVCAnmn88i9c8/77NPvP3fuzJ3JJHNduvDSNXvWXTP3nP349/9/+/sfe2ThC63XmJy/J1BMsSqarXONF6Ofdtz//v86/5nja/HNVnGajjWUi5Qz9EoD9u3itgtfHav/+Pu3XwOSqfQKvU77oB6Nac+SdKZgUYFHHvN2YcSaXINkSTg2joTg2fBiGvwEv8bB8PbbeswVZcp5MQEtuHF1YKjHlOjp28xWLC3kvULckETVgwHD4zGlGu/wR9GA/KOsOr5oTWpgHAw1aZY/nFCdnZ0Cn9Y4ZtMZ48fb29/92p49e5LRVqg5MHR3d+u+7+utra1q714mli5t9SH82H4Iuzt48KBTGrdXWJYVNTc3R7TpdevW8ZtvvvkC32dHGhqMvX84Vdf2THnX/cBNN627LYzU+9I0tTnnQVdX1yLDMHa/I8Bg2/XX1zdMvLKvrxBNmiT03z6/65UZ06d+sq+vLzyd6n0/vGnK1JbP9PYW4slTWmQcRQ+j/y0EhH9ce/PdhmF90TTD3tANlxuOsb22zfj7SxeG4bsNzfixbhgTlVJMCMGklFYhX7AMY/T5a44ZOGezLcs8OwhAavgiuX72oWPHPuwYxs9OpSLXdScwrl1r6frMLOExTVaMo7Po71WrVknbqbtU6lIzTWNSfyG/BI//34MhitnqXM6aCFCwOI53MM7uE0xMZrZ+5OBBt6Gp2ViKVGCJV9Q2NDeLo6SrmgMDZAqjKGL0oQa6R/6RrmAGOyUYAPu/NHRzpud5DHSYnQL8ypiEXIXrh5vCIFwTJ/EBTbDNv/+5q+0ZyNXaTsMCYgToI5EaWwXX8JtBqSfKbY5tfTCOoWM7/Wb5eS2CYVBmYoYMFJx/FKd/puM4B0aaAcERv2HN2s8RALB5ZMoYNKI5lrEB47+7cOHCnmrjj9o29+ml8/0W3bILDXQwkjgJLEu+OWLENPoO1gD/GsUaB0NmTxeb2Q8ktIEdmvzA/wSe3TVSDWvWdJ7DRfIhUCHjgu9DEWTWSMZzXTULczhdXS9Nqq+3DgRB0D9yHijmHBykdqVEnRCqXwnW1TJlykuIVWIAaRLGz4AswCV7C3jrCUO1EHOQW9pjGGKwiNat1NRcqBZhLvQnScQRFvvPAshHRjMh5ralZf2pCuM5jAmqwexTKnwO/fMj+9M+mFDnAfaT8E4JIffHpbn7qG9bW5uGAPGs5uZ4pkqZRWCAvAJ7W4jDUh/H4Ahq8L5JQgkFHZzoXNeVh0C/Wk0yw8DZpvL1EypJzmC6zIHvOna37b5n/p75w9MiHv2tbecklFpE/83Y6HUjyYHz+PaUW5eqNGQnThSX4aT8sqxo1w0Xa1K7JU35EqnrpqZpLEmy5CU4dOTIKseyvguLXq5ScTsV3aM4/BoK9w0Y81UARC/09//IMMxPI05x8nl3LQS9CqCcapl6tgSBVGnG0SCINjU01G0EEP3y2v39/sWGad2exuk5pmVnLo6a76WP4ddfD8noThNCXwfy6xBSNiH6gbtPIUvENGm97obx3Y4h70EWZUD0/5Sa1qZiJSleQAMoxH+oBFLzuMyaOuSgdwb0tYX8cIZbvNU1jTOjugIkY+gLoSXK0Ry4M6QuMN/YrVyODr1IjN0by2iaDYrrUlw9jf4XCaG9/4wdrYuZw35VoaQJKdc+kRk/Zb/G86cw7iujzG9pQpgJtIl+pdOB5vr+cqkb/y6l7tALrMe80PNgTLupaaLZ0xNkASkTTMfJMsllYe9Xw/CzKUg1TYsVi0VYhrG+E4WHHSe3jIxfMqgX4eBRiqslYAtD1zt7+grz3regfQW5KhjqXCm1RxDh52gM4h2XVmpoaLAC328dlDFNpzAht9iOs4D6EWA83w3AUSbFU3CN7zI0/W7X9SbisHy99fm5jXihx8VS38zihgn5h6xEQKB4gvSGfejlwyN5qrrTmP1vnFSHBhN7BR6IwhKg4HAUqfokHrsMMCSMzCA5ViMBhVI94MIHsKmLoHieeOpyjBsEA7C83DTMWbQxtB/BYCcodhjZKIiiPlm/lKrpgoFJpnGhbwJ4nCSJwQbxb1VCwZTcCZ3MPnHixKfJxgNzYaiiPswyrdlwtQfDKPxeFIYO08QB142vc3LOskzJSQIfnG4ABT+BlQzf964AkFf5oGXbsi/fubNri2UZD8Vx+jknl8tFUQgQxj8BgX8ZNK7ni/0XY+xZoHxBoEm96BvotqA0tzqkVPz1RBrbLBZP9v3gKgBqBVE+sVtr17ynBRdfdovFudjzGgBtcgz6iKPga9jzQewlQwQwcisCyhaAOw78YC101k3vZO6+fSsIkbnsyqGqxuFbkkXvWplc39F4NmOXVDVosNO8efH6J2+tbowUNlPx49BDN8DQjF0sh1FI+N5sAs6u1HVJpxObiR9TSi7Whg7+GGvIlThZ00mROHE7TUO7WJgD8zLxCgZvNevq68gIZXhp8KrQXyEV7G+Q6j6bqSzO4bom/z8xWIUazuNX6izjvorFn/O8UJeG+aUMiSm/Gu8ewrFsSVMFLOHiL2VPwTh7S/l/tja77LLL+JrOzjmMpx0EGMqOsPcrHcd6sjS3gR+2zfOjiRi7DDrRwC4dli0/T0Da8XzXtQD6ZLBdZBja9/GewJA114tWASgtyCZw3xxvQjhVoOeSbw6uYboxn0VedWBwbM5c9kQ6g29bd7R+HdNvslkpCzx9K7PUcfYvt7Lrsw2P1RDMmQiOCkUvfBTMchWM1+LH0cccQzwIX/9e0PmSASrcTAEXCk/IQ0/foNDMakg7LhlIvViq0jsGAVYxvCLQzKSHO2GB7/3ccUwAodSk9OYnSpxBfwMor81smfJDBJ3DhEg19h0Y9As6kAs4zGtsbJSed/RVeBEWxCG8gLYaft9ncfgQ9tFDg9evX5+6YbgITIRzisg/8LfncuYAEIamh+z3AtDLBp6cR9kVPhPwPcMw9MMB9gkAzCAY8FQjvdE7hBSN6FYCA1P+p1jO+DMW2GPpsfSeROtjPn52MMFXswasedra4MC05ePVkz6OJ1WBAVF9ZgRdY/cHQbgSRSPBYkU1hwdhzCsc25YwGJJp9gD1g3H5YEBwit3A6AOgT88sGTAKEVDurG7zNJR3VfaFomdbtpXtDuB8EUA42Q3G8VsoilE2QTFIfU9Pz2x4rk0IEz5r2/b0MIym6Zq4Gx747/0wvuf1V1++a/58BMpKzCa3l7lMbfi6QzLIl7AHhEMCW+cTNm7cmOvtBUHxzL6/U5OARz/rhzUDil+qaGkDOgmPIXYBQ+RZHg+qYYZBrq2q9zBB2tvbt4P2noMpzofCFyP4WowOHyElxUmyc0bLlKdHnsYqdpJ1oROCuxCGE1nVECh9WLwMW2l0wony0U51PQ/ReZIFaviUlnNeALtdirjjNjy/kHwe7Dlb141/PrN17nsx12eAbr2UHlJiJU515BTeV7J6htiqNjOiU02mliM3khWKuLgflHg+FO/EiboT2p9LNI9g9t+oFvC7bh7a8knR8Ks6WBM3euzFauYoUetQgysrUCUvM7RK55QDv2FzWVZzGsTTM5emWB5JQFY8cxzjOfz6c9Qs/gqu/TqY8CLKPE3DWAEXQZXBfTRvFviqBPHZKOaS8ZkiFbIEtPTYjTfe6MJNNPpVhekkhQ+hSgfhHQEGEtQyxGN+4G2A7Zo1TSyizXu+34cA8xEKpqptUGzmSaC6XQDCXKpYgmmuwqNfjJyDfPvYQNN2gaZPIB6YgIi+fUdXF92jDPftofo4fLZBTI7VdlN8Ujk33lCJfLPvR5txsbQ8ywhjsVBK9RuwVgo5udC0D6Po9B7HEcNAmybpZTpqGqUKbPrfFGtgj6dN34lsSrEW1xFIEtW/s8CAzR6F+A/rhn4tcnhm2TZlAY+BbkeWWk+LizLNo1TyAAKvT1IWAGV/CpTdzyz5TXA4qnHWRMQr1x46cmw/Stn3ZgnpKZrj8Dddnz8BMHQAVBTmfM/349XA3FMQkaHY9HGsua4UsFFuzzbRVIcPH98Ids8rQ/6gybaP9/b2It9HfEkmgifCRC7w83LRC54xdesCpJ91iDN+6PvqH1Ch3IFg2gKjrEQqeQ0xRxY3SP6D7Kz7WOU0jkKggpoxgZQC2UYHxt+JEsb8WmQG6A73a1mBaLh/5mnyQBgEFJULXFEjfhUPVdqI6ijlsRRzVbwbnBPZVKYmnLAtxWJwb66+7kvw28y0zM8jGL0ChwVpa1w/obGpvqe35zbqSwAqB3L09SRcKG2t53uLbdOehcuwswCyR1kaHfV8JArI9YkRUA9gyP8fRCbyKI1H1Ns2sbFpWU9P71f7gsKBlMsJWGMWrQOw7zdNmTEVT/lqyLcVe66HizwXNY4nURE47AcxLmn1ptJ+NRaE0YY6h9LdUgOqkLWSqFyDG+MA1qDYKk2ehVwUe1GyewvmQtrLmmsODBQMDaQ9OPkK1bMh1YMFnsEJ/hWKMEsKhcKOlulTnjopjSulTPQZPM2Vcw5lE4y98cZrfzdnztlFoYkvgh3q0OgfQGwaWiy6KSLDfbR6DJQhkispuWLesmQA1htIDZf5UfAthHIfosogDDeV3DhVDQGyPMrY32lqavingTIwWeswGaO+vr4RTNBICKV3MPwLSEVXQs7jJdAaz+Td8GOY8A6c6AWQkR5PJzeJ612WRNGRSAV3AAi3V4IU71VJVHCgLDFOuaHueCf29xe5nNNGzwCmZiqA1hwYUCD5NqpiP4WMYGd9V+Um6G8p2dUo185nqXxlpD+H4n4dhvFHUanjUnJccpUa4oxbozD6V1Ciqkwjs/SNsRvy+fD7CE6XhlE8Bw4XJXp1APbf3jKQpaDu/wiqfa9CqbT+qGkx4oTdnW2dF97yQudSz/XOw5GejmJGEd57n5eIXzQ74pVBIJCRbf0Gzw22KBb/CYw8DfetvVKwF48fP/r4jBkzhl2kNTjGtu3d3R9or2+6JCm6C2DgqTjxVHh7HS5jKw7JW5V6amlpyh86dOyzvhfT/y+HANybw9Z2OKqm0YWeW+zgmnYm4g7koer5mgMDTsQeyxJ7RoKg/B109zopAcY+qQvFFRhL/4qPNkQphsEBKr6rkiorB+Nf4V7Gd/rQORl8VWYdzLsfQBsA16mD1fV71iscr61wxVsr53dGGUI3n5bF4TKMzG2UG4Aw6tYvaG6m/ACBZhZsVrSTTUj/FQZ5B8r2RsY4I9vALepd2fPSnVrtMcOomhh/+LZooOaY4W3Z9fgio2pgHAzjwBjUwDgYxsEwqIH/AzVqglIzFa2qAAAAAElFTkSuQmCC
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
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.
|
|
|
Matt Fisher
> 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 messageShow 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.
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
Hope this helps.
![1504220459230_microsoft.png]() data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAIMAAAAdCAYAAACJ8d9VAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAA/ESURBVGhD7VoLlF1Ved57n32ed2Yyk8lzkhCYmLBGU0YSI2BajTQgjTWlVnHASDWCoCwbTQuhATINGslaVKCgGJdUAYtdq6wCwRXRKC5ilQA1JFMC4bVCAnmn88i9c8/77NPvP3fuzJ3JJHNduvDSNXvWXTP3nP349/9/+/sfe2ThC63XmJy/J1BMsSqarXONF6Ofdtz//v86/5nja/HNVnGajjWUi5Qz9EoD9u3itgtfHav/+Pu3XwOSqfQKvU77oB6Nac+SdKZgUYFHHvN2YcSaXINkSTg2joTg2fBiGvwEv8bB8PbbeswVZcp5MQEtuHF1YKjHlOjp28xWLC3kvULckETVgwHD4zGlGu/wR9GA/KOsOr5oTWpgHAw1aZY/nFCdnZ0Cn9Y4ZtMZ48fb29/92p49e5LRVqg5MHR3d+u+7+utra1q714mli5t9SH82H4Iuzt48KBTGrdXWJYVNTc3R7TpdevW8ZtvvvkC32dHGhqMvX84Vdf2THnX/cBNN627LYzU+9I0tTnnQVdX1yLDMHa/I8Bg2/XX1zdMvLKvrxBNmiT03z6/65UZ06d+sq+vLzyd6n0/vGnK1JbP9PYW4slTWmQcRQ+j/y0EhH9ce/PdhmF90TTD3tANlxuOsb22zfj7SxeG4bsNzfixbhgTlVJMCMGklFYhX7AMY/T5a44ZOGezLcs8OwhAavgiuX72oWPHPuwYxs9OpSLXdScwrl1r6frMLOExTVaMo7Po71WrVknbqbtU6lIzTWNSfyG/BI//34MhitnqXM6aCFCwOI53MM7uE0xMZrZ+5OBBt6Gp2ViKVGCJV9Q2NDeLo6SrmgMDZAqjKGL0oQa6R/6RrmAGOyUYAPu/NHRzpud5DHSYnQL8ypiEXIXrh5vCIFwTJ/EBTbDNv/+5q+0ZyNXaTsMCYgToI5EaWwXX8JtBqSfKbY5tfTCOoWM7/Wb5eS2CYVBmYoYMFJx/FKd/puM4B0aaAcERv2HN2s8RALB5ZMoYNKI5lrEB47+7cOHCnmrjj9o29+ml8/0W3bILDXQwkjgJLEu+OWLENPoO1gD/GsUaB0NmTxeb2Q8ktIEdmvzA/wSe3TVSDWvWdJ7DRfIhUCHjgu9DEWTWSMZzXTULczhdXS9Nqq+3DgRB0D9yHijmHBykdqVEnRCqXwnW1TJlykuIVWIAaRLGz4AswCV7C3jrCUO1EHOQW9pjGGKwiNat1NRcqBZhLvQnScQRFvvPAshHRjMh5ralZf2pCuM5jAmqwexTKnwO/fMj+9M+mFDnAfaT8E4JIffHpbn7qG9bW5uGAPGs5uZ4pkqZRWCAvAJ7W4jDUh/H4Ahq8L5JQgkFHZzoXNeVh0C/Wk0yw8DZpvL1EypJzmC6zIHvOna37b5n/p75w9MiHv2tbecklFpE/83Y6HUjyYHz+PaUW5eqNGQnThSX4aT8sqxo1w0Xa1K7JU35EqnrpqZpLEmy5CU4dOTIKseyvguLXq5ScTsV3aM4/BoK9w0Y81UARC/09//IMMxPI05x8nl3LQS9CqCcapl6tgSBVGnG0SCINjU01G0EEP3y2v39/sWGad2exuk5pmVnLo6a76WP4ddfD8noThNCXwfy6xBSNiH6gbtPIUvENGm97obx3Y4h70EWZUD0/5Sa1qZiJSleQAMoxH+oBFLzuMyaOuSgdwb0tYX8cIZbvNU1jTOjugIkY+gLoSXK0Ry4M6QuMN/YrVyODr1IjN0by2iaDYrrUlw9jf4XCaG9/4wdrYuZw35VoaQJKdc+kRk/Zb/G86cw7iujzG9pQpgJtIl+pdOB5vr+cqkb/y6l7tALrMe80PNgTLupaaLZ0xNkASkTTMfJMsllYe9Xw/CzKUg1TYsVi0VYhrG+E4WHHSe3jIxfMqgX4eBRiqslYAtD1zt7+grz3regfQW5KhjqXCm1RxDh52gM4h2XVmpoaLAC328dlDFNpzAht9iOs4D6EWA83w3AUSbFU3CN7zI0/W7X9SbisHy99fm5jXihx8VS38zihgn5h6xEQKB4gvSGfejlwyN5qrrTmP1vnFSHBhN7BR6IwhKg4HAUqfokHrsMMCSMzCA5ViMBhVI94MIHsKmLoHieeOpyjBsEA7C83DTMWbQxtB/BYCcodhjZKIiiPlm/lKrpgoFJpnGhbwJ4nCSJwQbxb1VCwZTcCZ3MPnHixKfJxgNzYaiiPswyrdlwtQfDKPxeFIYO08QB142vc3LOskzJSQIfnG4ABT+BlQzf964AkFf5oGXbsi/fubNri2UZD8Vx+jknl8tFUQgQxj8BgX8ZNK7ni/0XY+xZoHxBoEm96BvotqA0tzqkVPz1RBrbLBZP9v3gKgBqBVE+sVtr17ynBRdfdovFudjzGgBtcgz6iKPga9jzQewlQwQwcisCyhaAOw78YC101k3vZO6+fSsIkbnsyqGqxuFbkkXvWplc39F4NmOXVDVosNO8efH6J2+tbowUNlPx49BDN8DQjF0sh1FI+N5sAs6u1HVJpxObiR9TSi7Whg7+GGvIlThZ00mROHE7TUO7WJgD8zLxCgZvNevq68gIZXhp8KrQXyEV7G+Q6j6bqSzO4bom/z8xWIUazuNX6izjvorFn/O8UJeG+aUMiSm/Gu8ewrFsSVMFLOHiL2VPwTh7S/l/tja77LLL+JrOzjmMpx0EGMqOsPcrHcd6sjS3gR+2zfOjiRi7DDrRwC4dli0/T0Da8XzXtQD6ZLBdZBja9/GewJA114tWASgtyCZw3xxvQjhVoOeSbw6uYboxn0VedWBwbM5c9kQ6g29bd7R+HdNvslkpCzx9K7PUcfYvt7Lrsw2P1RDMmQiOCkUvfBTMchWM1+LH0cccQzwIX/9e0PmSASrcTAEXCk/IQ0/foNDMakg7LhlIvViq0jsGAVYxvCLQzKSHO2GB7/3ccUwAodSk9OYnSpxBfwMor81smfJDBJ3DhEg19h0Y9As6kAs4zGtsbJSed/RVeBEWxCG8gLYaft9ncfgQ9tFDg9evX5+6YbgITIRzisg/8LfncuYAEIamh+z3AtDLBp6cR9kVPhPwPcMw9MMB9gkAzCAY8FQjvdE7hBSN6FYCA1P+p1jO+DMW2GPpsfSeROtjPn52MMFXswasedra4MC05ePVkz6OJ1WBAVF9ZgRdY/cHQbgSRSPBYkU1hwdhzCsc25YwGJJp9gD1g3H5YEBwit3A6AOgT88sGTAKEVDurG7zNJR3VfaFomdbtpXtDuB8EUA42Q3G8VsoilE2QTFIfU9Pz2x4rk0IEz5r2/b0MIym6Zq4Gx747/0wvuf1V1++a/58BMpKzCa3l7lMbfi6QzLIl7AHhEMCW+cTNm7cmOvtBUHxzL6/U5OARz/rhzUDil+qaGkDOgmPIXYBQ+RZHg+qYYZBrq2q9zBB2tvbt4P2noMpzofCFyP4WowOHyElxUmyc0bLlKdHnsYqdpJ1oROCuxCGE1nVECh9WLwMW2l0wony0U51PQ/ReZIFaviUlnNeALtdirjjNjy/kHwe7Dlb141/PrN17nsx12eAbr2UHlJiJU515BTeV7J6htiqNjOiU02mliM3khWKuLgflHg+FO/EiboT2p9LNI9g9t+oFvC7bh7a8knR8Ks6WBM3euzFauYoUetQgysrUCUvM7RK55QDv2FzWVZzGsTTM5emWB5JQFY8cxzjOfz6c9Qs/gqu/TqY8CLKPE3DWAEXQZXBfTRvFviqBPHZKOaS8ZkiFbIEtPTYjTfe6MJNNPpVhekkhQ+hSgfhHQEGEtQyxGN+4G2A7Zo1TSyizXu+34cA8xEKpqptUGzmSaC6XQDCXKpYgmmuwqNfjJyDfPvYQNN2gaZPIB6YgIi+fUdXF92jDPftofo4fLZBTI7VdlN8Ujk33lCJfLPvR5txsbQ8ywhjsVBK9RuwVgo5udC0D6Po9B7HEcNAmybpZTpqGqUKbPrfFGtgj6dN34lsSrEW1xFIEtW/s8CAzR6F+A/rhn4tcnhm2TZlAY+BbkeWWk+LizLNo1TyAAKvT1IWAGV/CpTdzyz5TXA4qnHWRMQr1x46cmw/Stn3ZgnpKZrj8Dddnz8BMHQAVBTmfM/349XA3FMQkaHY9HGsua4UsFFuzzbRVIcPH98Ids8rQ/6gybaP9/b2It9HfEkmgifCRC7w83LRC54xdesCpJ91iDN+6PvqH1Ch3IFg2gKjrEQqeQ0xRxY3SP6D7Kz7WOU0jkKggpoxgZQC2UYHxt+JEsb8WmQG6A73a1mBaLh/5mnyQBgEFJULXFEjfhUPVdqI6ijlsRRzVbwbnBPZVKYmnLAtxWJwb66+7kvw28y0zM8jGL0ChwVpa1w/obGpvqe35zbqSwAqB3L09SRcKG2t53uLbdOehcuwswCyR1kaHfV8JArI9YkRUA9gyP8fRCbyKI1H1Ns2sbFpWU9P71f7gsKBlMsJWGMWrQOw7zdNmTEVT/lqyLcVe66HizwXNY4nURE47AcxLmn1ptJ+NRaE0YY6h9LdUgOqkLWSqFyDG+MA1qDYKk2ehVwUe1GyewvmQtrLmmsODBQMDaQ9OPkK1bMh1YMFnsEJ/hWKMEsKhcKOlulTnjopjSulTPQZPM2Vcw5lE4y98cZrfzdnztlFoYkvgh3q0OgfQGwaWiy6KSLDfbR6DJQhkispuWLesmQA1htIDZf5UfAthHIfosogDDeV3DhVDQGyPMrY32lqavingTIwWeswGaO+vr4RTNBICKV3MPwLSEVXQs7jJdAaz+Td8GOY8A6c6AWQkR5PJzeJ612WRNGRSAV3AAi3V4IU71VJVHCgLDFOuaHueCf29xe5nNNGzwCmZiqA1hwYUCD5NqpiP4WMYGd9V+Um6G8p2dUo185nqXxlpD+H4n4dhvFHUanjUnJccpUa4oxbozD6V1Ciqkwjs/SNsRvy+fD7CE6XhlE8Bw4XJXp1APbf3jKQpaDu/wiqfa9CqbT+qGkx4oTdnW2dF97yQudSz/XOw5GejmJGEd57n5eIXzQ74pVBIJCRbf0Gzw22KBb/CYw8DfetvVKwF48fP/r4jBkzhl2kNTjGtu3d3R9or2+6JCm6C2DgqTjxVHh7HS5jKw7JW5V6amlpyh86dOyzvhfT/y+HANybw9Z2OKqm0YWeW+zgmnYm4g7koer5mgMDTsQeyxJ7RoKg/B109zopAcY+qQvFFRhL/4qPNkQphsEBKr6rkiorB+Nf4V7Gd/rQORl8VWYdzLsfQBsA16mD1fV71iscr61wxVsr53dGGUI3n5bF4TKMzG2UG4Aw6tYvaG6m/ACBZhZsVrSTTUj/FQZ5B8r2RsY4I9vALepd2fPSnVrtMcOomhh/+LZooOaY4W3Z9fgio2pgHAzjwBjUwDgYxsEwqIH/AzVqglIzFa2qAAAAAElFTkSuQmCC
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
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 <justinleegarrison@...>
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.
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
Hope this helps.
![1504220459230_microsoft.png]() data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAIMAAAAdCAYAAACJ8d9VAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAA/ESURBVGhD7VoLlF1Ved57n32ed2Yyk8lzkhCYmLBGU0YSI2BajTQgjTWlVnHASDWCoCwbTQuhATINGslaVKCgGJdUAYtdq6wCwRXRKC5ilQA1JFMC4bVCAnmn88i9c8/77NPvP3fuzJ3JJHNduvDSNXvWXTP3nP349/9/+/sfe2ThC63XmJy/J1BMsSqarXONF6Ofdtz//v86/5nja/HNVnGajjWUi5Qz9EoD9u3itgtfHav/+Pu3XwOSqfQKvU77oB6Nac+SdKZgUYFHHvN2YcSaXINkSTg2joTg2fBiGvwEv8bB8PbbeswVZcp5MQEtuHF1YKjHlOjp28xWLC3kvULckETVgwHD4zGlGu/wR9GA/KOsOr5oTWpgHAw1aZY/nFCdnZ0Cn9Y4ZtMZ48fb29/92p49e5LRVqg5MHR3d+u+7+utra1q714mli5t9SH82H4Iuzt48KBTGrdXWJYVNTc3R7TpdevW8ZtvvvkC32dHGhqMvX84Vdf2THnX/cBNN627LYzU+9I0tTnnQVdX1yLDMHa/I8Bg2/XX1zdMvLKvrxBNmiT03z6/65UZ06d+sq+vLzyd6n0/vGnK1JbP9PYW4slTWmQcRQ+j/y0EhH9ce/PdhmF90TTD3tANlxuOsb22zfj7SxeG4bsNzfixbhgTlVJMCMGklFYhX7AMY/T5a44ZOGezLcs8OwhAavgiuX72oWPHPuwYxs9OpSLXdScwrl1r6frMLOExTVaMo7Po71WrVknbqbtU6lIzTWNSfyG/BI//34MhitnqXM6aCFCwOI53MM7uE0xMZrZ+5OBBt6Gp2ViKVGCJV9Q2NDeLo6SrmgMDZAqjKGL0oQa6R/6RrmAGOyUYAPu/NHRzpud5DHSYnQL8ypiEXIXrh5vCIFwTJ/EBTbDNv/+5q+0ZyNXaTsMCYgToI5EaWwXX8JtBqSfKbY5tfTCOoWM7/Wb5eS2CYVBmYoYMFJx/FKd/puM4B0aaAcERv2HN2s8RALB5ZMoYNKI5lrEB47+7cOHCnmrjj9o29+ml8/0W3bILDXQwkjgJLEu+OWLENPoO1gD/GsUaB0NmTxeb2Q8ktIEdmvzA/wSe3TVSDWvWdJ7DRfIhUCHjgu9DEWTWSMZzXTULczhdXS9Nqq+3DgRB0D9yHijmHBykdqVEnRCqXwnW1TJlykuIVWIAaRLGz4AswCV7C3jrCUO1EHOQW9pjGGKwiNat1NRcqBZhLvQnScQRFvvPAshHRjMh5ralZf2pCuM5jAmqwexTKnwO/fMj+9M+mFDnAfaT8E4JIffHpbn7qG9bW5uGAPGs5uZ4pkqZRWCAvAJ7W4jDUh/H4Ahq8L5JQgkFHZzoXNeVh0C/Wk0yw8DZpvL1EypJzmC6zIHvOna37b5n/p75w9MiHv2tbecklFpE/83Y6HUjyYHz+PaUW5eqNGQnThSX4aT8sqxo1w0Xa1K7JU35EqnrpqZpLEmy5CU4dOTIKseyvguLXq5ScTsV3aM4/BoK9w0Y81UARC/09//IMMxPI05x8nl3LQS9CqCcapl6tgSBVGnG0SCINjU01G0EEP3y2v39/sWGad2exuk5pmVnLo6a76WP4ddfD8noThNCXwfy6xBSNiH6gbtPIUvENGm97obx3Y4h70EWZUD0/5Sa1qZiJSleQAMoxH+oBFLzuMyaOuSgdwb0tYX8cIZbvNU1jTOjugIkY+gLoSXK0Ry4M6QuMN/YrVyODr1IjN0by2iaDYrrUlw9jf4XCaG9/4wdrYuZw35VoaQJKdc+kRk/Zb/G86cw7iujzG9pQpgJtIl+pdOB5vr+cqkb/y6l7tALrMe80PNgTLupaaLZ0xNkASkTTMfJMsllYe9Xw/CzKUg1TYsVi0VYhrG+E4WHHSe3jIxfMqgX4eBRiqslYAtD1zt7+grz3regfQW5KhjqXCm1RxDh52gM4h2XVmpoaLAC328dlDFNpzAht9iOs4D6EWA83w3AUSbFU3CN7zI0/W7X9SbisHy99fm5jXihx8VS38zihgn5h6xEQKB4gvSGfejlwyN5qrrTmP1vnFSHBhN7BR6IwhKg4HAUqfokHrsMMCSMzCA5ViMBhVI94MIHsKmLoHieeOpyjBsEA7C83DTMWbQxtB/BYCcodhjZKIiiPlm/lKrpgoFJpnGhbwJ4nCSJwQbxb1VCwZTcCZ3MPnHixKfJxgNzYaiiPswyrdlwtQfDKPxeFIYO08QB142vc3LOskzJSQIfnG4ABT+BlQzf964AkFf5oGXbsi/fubNri2UZD8Vx+jknl8tFUQgQxj8BgX8ZNK7ni/0XY+xZoHxBoEm96BvotqA0tzqkVPz1RBrbLBZP9v3gKgBqBVE+sVtr17ynBRdfdovFudjzGgBtcgz6iKPga9jzQewlQwQwcisCyhaAOw78YC101k3vZO6+fSsIkbnsyqGqxuFbkkXvWplc39F4NmOXVDVosNO8efH6J2+tbowUNlPx49BDN8DQjF0sh1FI+N5sAs6u1HVJpxObiR9TSi7Whg7+GGvIlThZ00mROHE7TUO7WJgD8zLxCgZvNevq68gIZXhp8KrQXyEV7G+Q6j6bqSzO4bom/z8xWIUazuNX6izjvorFn/O8UJeG+aUMiSm/Gu8ewrFsSVMFLOHiL2VPwTh7S/l/tja77LLL+JrOzjmMpx0EGMqOsPcrHcd6sjS3gR+2zfOjiRi7DDrRwC4dli0/T0Da8XzXtQD6ZLBdZBja9/GewJA114tWASgtyCZw3xxvQjhVoOeSbw6uYboxn0VedWBwbM5c9kQ6g29bd7R+HdNvslkpCzx9K7PUcfYvt7Lrsw2P1RDMmQiOCkUvfBTMchWM1+LH0cccQzwIX/9e0PmSASrcTAEXCk/IQ0/foNDMakg7LhlIvViq0jsGAVYxvCLQzKSHO2GB7/3ccUwAodSk9OYnSpxBfwMor81smfJDBJ3DhEg19h0Y9As6kAs4zGtsbJSed/RVeBEWxCG8gLYaft9ncfgQ9tFDg9evX5+6YbgITIRzisg/8LfncuYAEIamh+z3AtDLBp6cR9kVPhPwPcMw9MMB9gkAzCAY8FQjvdE7hBSN6FYCA1P+p1jO+DMW2GPpsfSeROtjPn52MMFXswasedra4MC05ePVkz6OJ1WBAVF9ZgRdY/cHQbgSRSPBYkU1hwdhzCsc25YwGJJp9gD1g3H5YEBwit3A6AOgT88sGTAKEVDurG7zNJR3VfaFomdbtpXtDuB8EUA42Q3G8VsoilE2QTFIfU9Pz2x4rk0IEz5r2/b0MIym6Zq4Gx747/0wvuf1V1++a/58BMpKzCa3l7lMbfi6QzLIl7AHhEMCW+cTNm7cmOvtBUHxzL6/U5OARz/rhzUDil+qaGkDOgmPIXYBQ+RZHg+qYYZBrq2q9zBB2tvbt4P2noMpzofCFyP4WowOHyElxUmyc0bLlKdHnsYqdpJ1oROCuxCGE1nVECh9WLwMW2l0wony0U51PQ/ReZIFaviUlnNeALtdirjjNjy/kHwe7Dlb141/PrN17nsx12eAbr2UHlJiJU515BTeV7J6htiqNjOiU02mliM3khWKuLgflHg+FO/EiboT2p9LNI9g9t+oFvC7bh7a8knR8Ks6WBM3euzFauYoUetQgysrUCUvM7RK55QDv2FzWVZzGsTTM5emWB5JQFY8cxzjOfz6c9Qs/gqu/TqY8CLKPE3DWAEXQZXBfTRvFviqBPHZKOaS8ZkiFbIEtPTYjTfe6MJNNPpVhekkhQ+hSgfhHQEGEtQyxGN+4G2A7Zo1TSyizXu+34cA8xEKpqptUGzmSaC6XQDCXKpYgmmuwqNfjJyDfPvYQNN2gaZPIB6YgIi+fUdXF92jDPftofo4fLZBTI7VdlN8Ujk33lCJfLPvR5txsbQ8ywhjsVBK9RuwVgo5udC0D6Po9B7HEcNAmybpZTpqGqUKbPrfFGtgj6dN34lsSrEW1xFIEtW/s8CAzR6F+A/rhn4tcnhm2TZlAY+BbkeWWk+LizLNo1TyAAKvT1IWAGV/CpTdzyz5TXA4qnHWRMQr1x46cmw/Stn3ZgnpKZrj8Dddnz8BMHQAVBTmfM/349XA3FMQkaHY9HGsua4UsFFuzzbRVIcPH98Ids8rQ/6gybaP9/b2It9HfEkmgifCRC7w83LRC54xdesCpJ91iDN+6PvqH1Ch3IFg2gKjrEQqeQ0xRxY3SP6D7Kz7WOU0jkKggpoxgZQC2UYHxt+JEsb8WmQG6A73a1mBaLh/5mnyQBgEFJULXFEjfhUPVdqI6ijlsRRzVbwbnBPZVKYmnLAtxWJwb66+7kvw28y0zM8jGL0ChwVpa1w/obGpvqe35zbqSwAqB3L09SRcKG2t53uLbdOehcuwswCyR1kaHfV8JArI9YkRUA9gyP8fRCbyKI1H1Ns2sbFpWU9P71f7gsKBlMsJWGMWrQOw7zdNmTEVT/lqyLcVe66HizwXNY4nURE47AcxLmn1ptJ+NRaE0YY6h9LdUgOqkLWSqFyDG+MA1qDYKk2ehVwUe1GyewvmQtrLmmsODBQMDaQ9OPkK1bMh1YMFnsEJ/hWKMEsKhcKOlulTnjopjSulTPQZPM2Vcw5lE4y98cZrfzdnztlFoYkvgh3q0OgfQGwaWiy6KSLDfbR6DJQhkispuWLesmQA1htIDZf5UfAthHIfosogDDeV3DhVDQGyPMrY32lqavingTIwWeswGaO+vr4RTNBICKV3MPwLSEVXQs7jJdAaz+Td8GOY8A6c6AWQkR5PJzeJ612WRNGRSAV3AAi3V4IU71VJVHCgLDFOuaHueCf29xe5nNNGzwCmZiqA1hwYUCD5NqpiP4WMYGd9V+Um6G8p2dUo185nqXxlpD+H4n4dhvFHUanjUnJccpUa4oxbozD6V1Ciqkwjs/SNsRvy+fD7CE6XhlE8Bw4XJXp1APbf3jKQpaDu/wiqfa9CqbT+qGkx4oTdnW2dF97yQudSz/XOw5GejmJGEd57n5eIXzQ74pVBIJCRbf0Gzw22KBb/CYw8DfetvVKwF48fP/r4jBkzhl2kNTjGtu3d3R9or2+6JCm6C2DgqTjxVHh7HS5jKw7JW5V6amlpyh86dOyzvhfT/y+HANybw9Z2OKqm0YWeW+zgmnYm4g7koer5mgMDTsQeyxJ7RoKg/B109zopAcY+qQvFFRhL/4qPNkQphsEBKr6rkiorB+Nf4V7Gd/rQORl8VWYdzLsfQBsA16mD1fV71iscr61wxVsr53dGGUI3n5bF4TKMzG2UG4Aw6tYvaG6m/ACBZhZsVrSTTUj/FQZ5B8r2RsY4I9vALepd2fPSnVrtMcOomhh/+LZooOaY4W3Z9fgio2pgHAzjwBjUwDgYxsEwqIH/AzVqglIzFa2qAAAAAElFTkSuQmCC
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
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.
|
|
|
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:
- 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
Hope this helps.
![1504220459230_microsoft.png]() data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAIMAAAAdCAYAAACJ8d9VAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAA/ESURBVGhD7VoLlF1Ved57n32ed2Yyk8lzkhCYmLBGU0YSI2BajTQgjTWlVnHASDWCoCwbTQuhATINGslaVKCgGJdUAYtdq6wCwRXRKC5ilQA1JFMC4bVCAnmn88i9c8/77NPvP3fuzJ3JJHNduvDSNXvWXTP3nP349/9/+/sfe2ThC63XmJy/J1BMsSqarXONF6Ofdtz//v86/5nja/HNVnGajjWUi5Qz9EoD9u3itgtfHav/+Pu3XwOSqfQKvU77oB6Nac+SdKZgUYFHHvN2YcSaXINkSTg2joTg2fBiGvwEv8bB8PbbeswVZcp5MQEtuHF1YKjHlOjp28xWLC3kvULckETVgwHD4zGlGu/wR9GA/KOsOr5oTWpgHAw1aZY/nFCdnZ0Cn9Y4ZtMZ48fb29/92p49e5LRVqg5MHR3d+u+7+utra1q714mli5t9SH82H4Iuzt48KBTGrdXWJYVNTc3R7TpdevW8ZtvvvkC32dHGhqMvX84Vdf2THnX/cBNN627LYzU+9I0tTnnQVdX1yLDMHa/I8Bg2/XX1zdMvLKvrxBNmiT03z6/65UZ06d+sq+vLzyd6n0/vGnK1JbP9PYW4slTWmQcRQ+j/y0EhH9ce/PdhmF90TTD3tANlxuOsb22zfj7SxeG4bsNzfixbhgTlVJMCMGklFYhX7AMY/T5a44ZOGezLcs8OwhAavgiuX72oWPHPuwYxs9OpSLXdScwrl1r6frMLOExTVaMo7Po71WrVknbqbtU6lIzTWNSfyG/BI//34MhitnqXM6aCFCwOI53MM7uE0xMZrZ+5OBBt6Gp2ViKVGCJV9Q2NDeLo6SrmgMDZAqjKGL0oQa6R/6RrmAGOyUYAPu/NHRzpud5DHSYnQL8ypiEXIXrh5vCIFwTJ/EBTbDNv/+5q+0ZyNXaTsMCYgToI5EaWwXX8JtBqSfKbY5tfTCOoWM7/Wb5eS2CYVBmYoYMFJx/FKd/puM4B0aaAcERv2HN2s8RALB5ZMoYNKI5lrEB47+7cOHCnmrjj9o29+ml8/0W3bILDXQwkjgJLEu+OWLENPoO1gD/GsUaB0NmTxeb2Q8ktIEdmvzA/wSe3TVSDWvWdJ7DRfIhUCHjgu9DEWTWSMZzXTULczhdXS9Nqq+3DgRB0D9yHijmHBykdqVEnRCqXwnW1TJlykuIVWIAaRLGz4AswCV7C3jrCUO1EHOQW9pjGGKwiNat1NRcqBZhLvQnScQRFvvPAshHRjMh5ralZf2pCuM5jAmqwexTKnwO/fMj+9M+mFDnAfaT8E4JIffHpbn7qG9bW5uGAPGs5uZ4pkqZRWCAvAJ7W4jDUh/H4Ahq8L5JQgkFHZzoXNeVh0C/Wk0yw8DZpvL1EypJzmC6zIHvOna37b5n/p75w9MiHv2tbecklFpE/83Y6HUjyYHz+PaUW5eqNGQnThSX4aT8sqxo1w0Xa1K7JU35EqnrpqZpLEmy5CU4dOTIKseyvguLXq5ScTsV3aM4/BoK9w0Y81UARC/09//IMMxPI05x8nl3LQS9CqCcapl6tgSBVGnG0SCINjU01G0EEP3y2v39/sWGad2exuk5pmVnLo6a76WP4ddfD8noThNCXwfy6xBSNiH6gbtPIUvENGm97obx3Y4h70EWZUD0/5Sa1qZiJSleQAMoxH+oBFLzuMyaOuSgdwb0tYX8cIZbvNU1jTOjugIkY+gLoSXK0Ry4M6QuMN/YrVyODr1IjN0by2iaDYrrUlw9jf4XCaG9/4wdrYuZw35VoaQJKdc+kRk/Zb/G86cw7iujzG9pQpgJtIl+pdOB5vr+cqkb/y6l7tALrMe80PNgTLupaaLZ0xNkASkTTMfJMsllYe9Xw/CzKUg1TYsVi0VYhrG+E4WHHSe3jIxfMqgX4eBRiqslYAtD1zt7+grz3regfQW5KhjqXCm1RxDh52gM4h2XVmpoaLAC328dlDFNpzAht9iOs4D6EWA83w3AUSbFU3CN7zI0/W7X9SbisHy99fm5jXihx8VS38zihgn5h6xEQKB4gvSGfejlwyN5qrrTmP1vnFSHBhN7BR6IwhKg4HAUqfokHrsMMCSMzCA5ViMBhVI94MIHsKmLoHieeOpyjBsEA7C83DTMWbQxtB/BYCcodhjZKIiiPlm/lKrpgoFJpnGhbwJ4nCSJwQbxb1VCwZTcCZ3MPnHixKfJxgNzYaiiPswyrdlwtQfDKPxeFIYO08QB142vc3LOskzJSQIfnG4ABT+BlQzf964AkFf5oGXbsi/fubNri2UZD8Vx+jknl8tFUQgQxj8BgX8ZNK7ni/0XY+xZoHxBoEm96BvotqA0tzqkVPz1RBrbLBZP9v3gKgBqBVE+sVtr17ynBRdfdovFudjzGgBtcgz6iKPga9jzQewlQwQwcisCyhaAOw78YC101k3vZO6+fSsIkbnsyqGqxuFbkkXvWplc39F4NmOXVDVosNO8efH6J2+tbowUNlPx49BDN8DQjF0sh1FI+N5sAs6u1HVJpxObiR9TSi7Whg7+GGvIlThZ00mROHE7TUO7WJgD8zLxCgZvNevq68gIZXhp8KrQXyEV7G+Q6j6bqSzO4bom/z8xWIUazuNX6izjvorFn/O8UJeG+aUMiSm/Gu8ewrFsSVMFLOHiL2VPwTh7S/l/tja77LLL+JrOzjmMpx0EGMqOsPcrHcd6sjS3gR+2zfOjiRi7DDrRwC4dli0/T0Da8XzXtQD6ZLBdZBja9/GewJA114tWASgtyCZw3xxvQjhVoOeSbw6uYboxn0VedWBwbM5c9kQ6g29bd7R+HdNvslkpCzx9K7PUcfYvt7Lrsw2P1RDMmQiOCkUvfBTMchWM1+LH0cccQzwIX/9e0PmSASrcTAEXCk/IQ0/foNDMakg7LhlIvViq0jsGAVYxvCLQzKSHO2GB7/3ccUwAodSk9OYnSpxBfwMor81smfJDBJ3DhEg19h0Y9As6kAs4zGtsbJSed/RVeBEWxCG8gLYaft9ncfgQ9tFDg9evX5+6YbgITIRzisg/8LfncuYAEIamh+z3AtDLBp6cR9kVPhPwPcMw9MMB9gkAzCAY8FQjvdE7hBSN6FYCA1P+p1jO+DMW2GPpsfSeROtjPn52MMFXswasedra4MC05ePVkz6OJ1WBAVF9ZgRdY/cHQbgSRSPBYkU1hwdhzCsc25YwGJJp9gD1g3H5YEBwit3A6AOgT88sGTAKEVDurG7zNJR3VfaFomdbtpXtDuB8EUA42Q3G8VsoilE2QTFIfU9Pz2x4rk0IEz5r2/b0MIym6Zq4Gx747/0wvuf1V1++a/58BMpKzCa3l7lMbfi6QzLIl7AHhEMCW+cTNm7cmOvtBUHxzL6/U5OARz/rhzUDil+qaGkDOgmPIXYBQ+RZHg+qYYZBrq2q9zBB2tvbt4P2noMpzofCFyP4WowOHyElxUmyc0bLlKdHnsYqdpJ1oROCuxCGE1nVECh9WLwMW2l0wony0U51PQ/ReZIFaviUlnNeALtdirjjNjy/kHwe7Dlb141/PrN17nsx12eAbr2UHlJiJU515BTeV7J6htiqNjOiU02mliM3khWKuLgflHg+FO/EiboT2p9LNI9g9t+oFvC7bh7a8knR8Ks6WBM3euzFauYoUetQgysrUCUvM7RK55QDv2FzWVZzGsTTM5emWB5JQFY8cxzjOfz6c9Qs/gqu/TqY8CLKPE3DWAEXQZXBfTRvFviqBPHZKOaS8ZkiFbIEtPTYjTfe6MJNNPpVhekkhQ+hSgfhHQEGEtQyxGN+4G2A7Zo1TSyizXu+34cA8xEKpqptUGzmSaC6XQDCXKpYgmmuwqNfjJyDfPvYQNN2gaZPIB6YgIi+fUdXF92jDPftofo4fLZBTI7VdlN8Ujk33lCJfLPvR5txsbQ8ywhjsVBK9RuwVgo5udC0D6Po9B7HEcNAmybpZTpqGqUKbPrfFGtgj6dN34lsSrEW1xFIEtW/s8CAzR6F+A/rhn4tcnhm2TZlAY+BbkeWWk+LizLNo1TyAAKvT1IWAGV/CpTdzyz5TXA4qnHWRMQr1x46cmw/Stn3ZgnpKZrj8Dddnz8BMHQAVBTmfM/349XA3FMQkaHY9HGsua4UsFFuzzbRVIcPH98Ids8rQ/6gybaP9/b2It9HfEkmgifCRC7w83LRC54xdesCpJ91iDN+6PvqH1Ch3IFg2gKjrEQqeQ0xRxY3SP6D7Kz7WOU0jkKggpoxgZQC2UYHxt+JEsb8WmQG6A73a1mBaLh/5mnyQBgEFJULXFEjfhUPVdqI6ijlsRRzVbwbnBPZVKYmnLAtxWJwb66+7kvw28y0zM8jGL0ChwVpa1w/obGpvqe35zbqSwAqB3L09SRcKG2t53uLbdOehcuwswCyR1kaHfV8JArI9YkRUA9gyP8fRCbyKI1H1Ns2sbFpWU9P71f7gsKBlMsJWGMWrQOw7zdNmTEVT/lqyLcVe66HizwXNY4nURE47AcxLmn1ptJ+NRaE0YY6h9LdUgOqkLWSqFyDG+MA1qDYKk2ehVwUe1GyewvmQtrLmmsODBQMDaQ9OPkK1bMh1YMFnsEJ/hWKMEsKhcKOlulTnjopjSulTPQZPM2Vcw5lE4y98cZrfzdnztlFoYkvgh3q0OgfQGwaWiy6KSLDfbR6DJQhkispuWLesmQA1htIDZf5UfAthHIfosogDDeV3DhVDQGyPMrY32lqavingTIwWeswGaO+vr4RTNBICKV3MPwLSEVXQs7jJdAaz+Td8GOY8A6c6AWQkR5PJzeJ612WRNGRSAV3AAi3V4IU71VJVHCgLDFOuaHueCf29xe5nNNGzwCmZiqA1hwYUCD5NqpiP4WMYGd9V+Um6G8p2dUo185nqXxlpD+H4n4dhvFHUanjUnJccpUa4oxbozD6V1Ciqkwjs/SNsRvy+fD7CE6XhlE8Bw4XJXp1APbf3jKQpaDu/wiqfa9CqbT+qGkx4oTdnW2dF97yQudSz/XOw5GejmJGEd57n5eIXzQ74pVBIJCRbf0Gzw22KBb/CYw8DfetvVKwF48fP/r4jBkzhl2kNTjGtu3d3R9or2+6JCm6C2DgqTjxVHh7HS5jKw7JW5V6amlpyh86dOyzvhfT/y+HANybw9Z2OKqm0YWeW+zgmnYm4g7koer5mgMDTsQeyxJ7RoKg/B109zopAcY+qQvFFRhL/4qPNkQphsEBKr6rkiorB+Nf4V7Gd/rQORl8VWYdzLsfQBsA16mD1fV71iscr61wxVsr53dGGUI3n5bF4TKMzG2UG4Aw6tYvaG6m/ACBZhZsVrSTTUj/FQZ5B8r2RsY4I9vALepd2fPSnVrtMcOomhh/+LZooOaY4W3Z9fgio2pgHAzjwBjUwDgYxsEwqIH/AzVqglIzFa2qAAAAAElFTkSuQmCC
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
toggle quoted messageShow quoted text
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 <justinleegarrison@...>
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.
|
|
|
Proposal: NOTES.txt rendering are the end of the install lifecycle
Guillaume Berche
Hi, Following the HIP process, I'd like to know whether the use-case below already received some thoughts, and whether there are some suggestions on best user experience to support this use-case. I have so far only submitted https://github.com/helm/helm/issues/9391 and would like to gather feedback on alternative UX before contributing a HIP PR.
Expected behavior
As a helm chart author
- in order for NOTES.txt template to display value looked up in status of K8S resources installed by the chart (say a URL to a webui managed service provisionned in a public cloud, and this url is'nt predictable at installation time)
- I need a way for the NOTES.txt template to render during the
post-install step of the install lifecycle.
See concrete example in https://github.com/orange-cloudfoundry/osb-to-helm-poc/blob/0c285e7c9de1f08898f55bc274d256de21297f0d/NOTES.txt.tpl#L1-L16
Observed behavior
NOTES.txt template is rendered before the pre-install step of the install lifecycle therefore the following NOTES.txt content
{{ $fullName:=include "p-mysql.fullname" . -}}
{{ $serviceInstance:= ( lookup "servicecatalog.k8s.io/v1beta1" "ServiceInstance" .Release.Namespace $fullName) -}}
{{- if $serviceInstance }}
You may access the managed service dashboard through:
{{ $serviceInstance.status.dashboardURL }}
ps: you're seeing this because NOTES.txt template was refreshed during last chart update.
{{ else }}
Dashboard url may be accessed through the following command:
kubectl get ServiceInstance -n {{.Release.Namespace}} {{$fullName}} -o jsonpath='{.status.dashboardURL}'
You may also try to update this helm chart to have this NOTES.txt template refreshed with resource looked up
{{ end }}
will render as the following as a result of `helm install`
Dashboard url may be accessed through the following command:
kubectl get ServiceInstance -n my-namespace my-service -o jsonpath='{.status.dashboardURL}'
You may also try to update this helm chart to have this NOTES.txt template refreshed with resource looked up
If helm upgrade is executed, then NOTES.txt is rendered instead as:
You may access the managed service dashboard through:
https://sample-service.a-public-provider.org/a-dynamically-generated-guid
ps: you're seeing this because NOTES.txt template was refreshed during last chart update.
Alternative chart author and chart user experiences
1. NOTES.txt template rendering now gets executed after the last chart hook in the install lifecycle. E.g. if a chart has both a pre-install and post-install hooks then the NOTES.txt renders after the post-install hook is "Ready" (instead of before the pre-install hooks AFAIK). I'm not sure whether this is considered a breaking change according to semantic versionning applies to helm. 2. a new opt-in to select in which phases the NOTES.txt template is rendered or possibly re-rendered/refreshed. Definitively a major version according to semantic versionning. This is more complex and likely outside of the scope of this proposal. Might be useful a way to provide progress feedback during install lifecycle. Thanks in advance for your feedback and alternative suggestions. Guillaume.
|
|
|
Re: Helm Test: What kind of tests can we perform on a helm chart?
Guillaume Berche
|
|
|
Re: Pre-proposal idea: introduce a new flag for helm uninstall "--fail-on-error" and a new release status "failed-uninstall"
Big +1 from me!
When trying to automate chart uninstalls (e.g. in the context of operator-sdk's helm-operator), it is fairly unintuitive and complex to set things up in such a way to guarantee resource cleanup. Off the top of my head, the following must happen:
1. All uninstall attempts must set `--keep-history=true`
2. Prior to making each subsequent uninstall attempt, the latest release status must be set to something other than `Uninstalled`.
|
|
|
Deprecation Notice for ChartCenter.io
|
|
|
Why are dependencies embedded rather than resolved?
You'll have to forgive my ignorance on this one, but there is nothing I can see that explains this design decision--and it really makes creating multi-service deployments harder than it should be.
In almost every package management system I am used to, the dependencies are resolved. The distinction is realized with transitive dependencies. For example, in a C# project, I can require 2 libraries, and each of those libraries can in turn require the same logging API dependency. The package management system figures out the version that satisfies the need for both transitive dependencies and either loads it at build time or sets up a dependency lock file for users to override if necessary.
Conversely, Helm embeds dependencies. That means if my chart depends on another chart, that dependency is copied into my chart. If I have two dependencies that in turn have the same dependency (like a configmap to hold a common logging configuration file) Helm will generate that transitive dependency multiple times. Once for each dependency. Obviously you can't have multiple configmaps with the same name.
I'm assuming the choice here was deliberate, but it is the choice that violates how I expect package management systems to behave the most. So I find myself having to rethink everything. Even OS level package managers like rpm and yum resolve dependencies at install time. What is the rationale here?
-- Berin Loritsch
DOMEX Architect 
7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708
|
|
|
Re: Pre-proposal idea: introduce a new flag for helm uninstall "--fail-on-error" and a new release status "failed-uninstall"
Joshua Packer
Hi Mike,
This seems like it could be very useful, especially during dev where there are more likely to be issues in the uninstall of the resources. Keeping the release would allow would give us a starting point to work from to recover, as you mention in your idea. Being an opt-in strategy, remove adverse affects for those with processes that expect the existing behavior.
Joshua Packer
|
|
|
Re: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints
Matt Fisher
So if I’m understanding correctly, you’re looking to validate that a particular resource provided by the user follows a certain schema.
Kubernetes resources define a schema (also known as a GroupVersionKind, or a GVK) which determines whether the resource is well-formed or not. Custom resources can be defined by the user to conform to a custom schema defined by the cluster
operator.
In this case, I would not put the validation logic in the Helm chart, as Matt suggested. Instead, I’d recommend creating a new resource definition that conforms to the schema you desire, then when the user creates new instances of that
resource, it will be validated and accepted (or rejected) by the Kubernetes API. Your Helm chart will only need to refer to the resource by its name, and the chart can safely rely on the schema’s validation logic to ensure that the correct data has been provided
in the correct fields.
Hope that helps.
toggle quoted messageShow quoted text
From: cncf-helm@... <cncf-helm@...>
On Behalf Of Loritsch, Berin via lists.cncf.io
Sent: Monday, January 18, 2021 5:41 AM
To: Matt Butcher <Matt.Butcher@...>
Cc: cncf-helm@...
Subject: Re: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints
The idea is not to scan, but to validate that the specified secret is the right kind. I.e. the user specifies `example-secret`, and the helm chart fails if the secret that exists is not the right kind... i.e. they accidentally supplied
a basic-auth secret or something like that. The ability to fail fast and provide a comprehensible error message is rather important.
The preferred method is requiring the user to set a value that points to an existing secret. If the user points to the wrong thing, then Helm should fail to deploy that release.
We advise people not to write charts that try to scan for SSL certificates on clusters, as that is a security warning sign. So I would advise not using
lookup in this (or any) case.
Helm is not and should not be used as a release manager tool. It is a package manager whose dependencies should be calculated up front and whose configuration should be passed by a user, not autoconfigured.
In other words, think of Helm as 'apt-get', not 'chef' or 'puppet'.
It appears this did not garner any attention. Is there any way to enforce constraints on a chart's dependencies?
For example, I would like to have my chart enforce a specific _type_ of secret the consumer provides.
My container can use TLS secrets and make use of them if they are provided. However, it won't make sense if the user supplies a service account token or basic-auth token. It would be fine if the secret is not provided at all, but if it
is provided it should be a specific type.
I am clear on how to create the templates, and mount the secret to my container. I'm not clear on how to enforce rather important constraints like that.
On Tue, Jan 12, 2021 at 10:17 AM Loritsch, Berin <bloritsch@...> wrote:
Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart.
In my chart I want to enforce that the provided Secret is the type:
kubernetes.io/tls
I want that constraint enforced prior to deploying the chart.
--
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
--
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
--
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
|
|
|
Re: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints
The idea is not to scan, but to validate that the specified secret is the right kind. I.e. the user specifies `example-secret`, and the helm chart fails if the secret that exists is not the right kind... i.e. they accidentally supplied a basic-auth secret or something like that. The ability to fail fast and provide a comprehensible error message is rather important.
The preferred method is requiring the user to set a value that points to an existing secret. If the user points to the wrong thing, then Helm should fail to deploy that release.
We advise people not to write charts that try to scan for SSL certificates on clusters, as that is a security warning sign. So I would advise not using
lookup in this (or any) case.
Helm is not and should not be used as a release manager tool. It is a package manager whose dependencies should be calculated up front and whose configuration should be passed by a user, not autoconfigured. In other words, think of Helm as 'apt-get', not 'chef'
or 'puppet'.
It appears this did not garner any attention. Is there any way to enforce constraints on a chart's dependencies?
For example, I would like to have my chart enforce a specific _type_ of secret the consumer provides.
My container can use TLS secrets and make use of them if they are provided. However, it won't make sense if the user supplies a service account token or basic-auth token. It would be fine if the secret is not provided at all, but if it is provided it
should be a specific type.
I am clear on how to create the templates, and mount the secret to my container. I'm not clear on how to enforce rather important constraints like that.
On Tue, Jan 12, 2021 at 10:17 AM Loritsch, Berin < bloritsch@...> wrote:
Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart.
In my chart I want to enforce that the provided Secret is the type:
kubernetes.io/tls
I want that constraint enforced prior to deploying the chart.
--
Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
--
Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
-- Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708
|
|
|
Re: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints
The preferred method is requiring the user to set a value that points to an existing secret. If the user points to the wrong thing, then Helm should fail to deploy that release.
We advise people not to write charts that try to scan for SSL certificates on clusters, as that is a security warning sign. So I would advise not using
lookup in this (or any) case.
Helm is not and should not be used as a release manager tool. It is a package manager whose dependencies should be calculated up front and whose configuration should be passed by a user, not autoconfigured. In other words, think of Helm as 'apt-get', not 'chef'
or 'puppet'.
toggle quoted messageShow quoted text
From: cncf-helm@... <cncf-helm@...> on behalf of Loritsch, Berin via lists.cncf.io <bloritsch=novetta.com@...>
Sent: Friday, January 15, 2021 12:46 PM
To: cncf-helm@... <cncf-helm@...>
Subject: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints
It appears this did not garner any attention. Is there any way to enforce constraints on a chart's dependencies?
For example, I would like to have my chart enforce a specific _type_ of secret the consumer provides.
My container can use TLS secrets and make use of them if they are provided. However, it won't make sense if the user supplies a service account token or basic-auth token. It would be fine if the secret is not provided at all, but if it is provided it
should be a specific type.
I am clear on how to create the templates, and mount the secret to my container. I'm not clear on how to enforce rather important constraints like that.
On Tue, Jan 12, 2021 at 10:17 AM Loritsch, Berin < bloritsch@...> wrote:
Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart.
In my chart I want to enforce that the provided Secret is the type:
kubernetes.io/tls
I want that constraint enforced prior to deploying the chart.
--
Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
--
Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
|
|
|
Re: Is there any way to enforce constraints
toggle quoted messageShow quoted text
Would 2pm work for you on monday?
Hey Berin,
I’m not sure if this completely answers the question, but the helm lookup function (https://helm.sh/docs/chart_template_guide/functions_and_pipelines/) may
be usable here to introspect the secret and make sure it has the correct type or the correct keys in the data.
It appears this did not garner any attention. Is there any way to enforce constraints on a chart's dependencies?
For example, I would like to have my chart enforce a specific _type_ of secret the consumer provides.
My container can use TLS secrets and make use of them if they are provided. However, it won't make sense if the user supplies a service account token or basic-auth token. It would be fine if the secret is not provided at all, but if it
is provided it should be a specific type.
I am clear on how to create the templates, and mount the secret to my container. I'm not clear on how to enforce rather important constraints like that.
On Tue, Jan 12, 2021 at 10:17 AM Loritsch, Berin <bloritsch@...> wrote:
Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart.
In my chart I want to enforce that the provided Secret is the type:
kubernetes.io/tls
I want that constraint enforced prior to deploying the chart.
--
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
--
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
--
Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708
-- Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708
|
|
|
Re: Is there any way to enforce constraints
Would 2pm work for you on monday?
Hey Berin,
I’m not sure if this completely answers the question, but the helm lookup function (https://helm.sh/docs/chart_template_guide/functions_and_pipelines/) may
be usable here to introspect the secret and make sure it has the correct type or the correct keys in the data.
It appears this did not garner any attention. Is there any way to enforce constraints on a chart's dependencies?
For example, I would like to have my chart enforce a specific _type_ of secret the consumer provides.
My container can use TLS secrets and make use of them if they are provided. However, it won't make sense if the user supplies a service account token or basic-auth token. It would be fine if the secret is not provided at all, but if it
is provided it should be a specific type.
I am clear on how to create the templates, and mount the secret to my container. I'm not clear on how to enforce rather important constraints like that.
On Tue, Jan 12, 2021 at 10:17 AM Loritsch, Berin <bloritsch@...> wrote:
Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart.
In my chart I want to enforce that the provided Secret is the type:
kubernetes.io/tls
I want that constraint enforced prior to deploying the chart.
--
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
--
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
-- Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708
|
|
|
Re: Is there any way to enforce constraints
toggle quoted messageShow quoted text
From: cncf-helm@... <cncf-helm@...>
On Behalf Of Loritsch, Berin via lists.cncf.io
Sent: Friday, January 15, 2021 1:47 PM
To: cncf-helm@...
Subject: Re: [cncf-helm] Is there any way to enforce constraints
It appears this did not garner any attention. Is there any way to enforce constraints on a chart's dependencies?
For example, I would like to have my chart enforce a specific _type_ of secret the consumer provides.
My container can use TLS secrets and make use of them if they are provided. However, it won't make sense if the user supplies a service account token or basic-auth token. It would be fine if the secret is not provided at all, but if it
is provided it should be a specific type.
I am clear on how to create the templates, and mount the secret to my container. I'm not clear on how to enforce rather important constraints like that.
On Tue, Jan 12, 2021 at 10:17 AM Loritsch, Berin <bloritsch@...> wrote:
Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart.
In my chart I want to enforce that the provided Secret is the type:
kubernetes.io/tls
I want that constraint enforced prior to deploying the chart.
--
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
--
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email
bloritsch@...
Office
(703) 735-6281
Mobile
(571) 215-7708
|
|
|
Re: Is there any way to enforce constraints
It appears this did not garner any attention. Is there any way to enforce constraints on a chart's dependencies?
For example, I would like to have my chart enforce a specific _type_ of secret the consumer provides.
My container can use TLS secrets and make use of them if they are provided. However, it won't make sense if the user supplies a service account token or basic-auth token. It would be fine if the secret is not provided at all, but if it is provided it should be a specific type.
I am clear on how to create the templates, and mount the secret to my container. I'm not clear on how to enforce rather important constraints like that.
On Tue, Jan 12, 2021 at 10:17 AM Loritsch, Berin < bloritsch@...> wrote: Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart.
In my chart I want to enforce that the provided Secret is the type:
kubernetes.io/tls
I want that constraint enforced prior to deploying the chart.
-- Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708
-- Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708
|
|
|
Pre-proposal idea: introduce a new flag for helm uninstall "--fail-on-error" and a new release status "failed-uninstall"
Hi all,
Following the HIP guide. I am looking for feedback regarding my idea below:
The current Helm uninstall implementation is marking release record as uninstalled even if Helm detected errors during the uninstall process. See:
https://github.com/helm/helm/blob/v3.4.2/pkg/action/uninstall.go#L122-L127
https://github.com/helm/helm/blob/v3.4.2/pkg/action/uninstall.go#L144-L150
If the release record is marked as uninstalled then re-attempting to helm uninstall doesn't actually delete any resources (just purge the release record) . See:
https://github.com/helm/helm/blob/v3.4.2/pkg/action/uninstall.go#L81-L91
I think it's very useful for scripts or automation tools to be able to re-attempt a helm uninstall that resulted in error.
That's why I am sharing my idea of adding a new flag to helm uninstall "--fail-on-error".
If this flag is enabled, and the helm uninstall is successful then it doesn't change any behavior.
If this flag is enabled, and the helm uninstall completed with errors then update the release record to "failed-uninstall" status.
This allows the next helm uninstall attempt to actually perform resources delete.
For reference, I initially suggested https://github.com/helm/helm/issues/9201 but after thinking about it I think this "--fail-on-error" idea is much clearer and cleaner.
Thank you for reading and please provide some feedback. I am willing to drive the implementation if needed.
Mike Ng
|
|
|
Re: Proposed dates for 3.6 release
Marc Khouzam
There was no objections to the proposed dates for 3.6. So with today's 3.5 release the 3.6 dates can be announced as:
3.6 RC1: Monday May 17th, 20213.6 final release: Wednesday May 26th, 2021
Thanks
Hi,
helm 3.5 will be released next week Wednesday, January 13th as previously announced. At the same time we should announce when the 3.6 release is planned. On the dev call today it was suggested:
3.6 RC1: Monday May 17th, 2021 3.6 final release: Wednesday May 26th, 2021 That date is about a month following the release of Kubernetes 1.21 to give maintainers enough time to adapt helm to any unexpected changes to Kubernetes's Go API.
Does anyone have concerns about those dates? (there is a holiday very close following which may affect maintainers availability).
Let's do a lazy consensus, so if there are no objections by next Tuesday, we'll announce the above dates the next day.
Thank you
|
|
|
