Date   

Re: Stepping down as an Org Maintainer

Matt Farina
 

Vic,

Thanks for all your time and hard work on Helm. We couldn't have pulled off all that charts CI without you. I wish you the best in the projects your working on and the family time.

- Matt Farina

On Wed, May 19, 2021, at 7:00 PM, Vic Iglesias via lists.cncf.io wrote:
Team,

I've been apart from the day to day of Helm, Charts and the rest of the ecosystem for a while now due to many factors but overwhelmingly because of the birth of my wonderful two boys over the last few years and my role change at Google to the PM organization.

My time working with you all has been some of the best I've experienced in my life. It was fulfilling, challenging and most of all extremely fun to be a part of this wonderful community of both developers and users.

Thank you for the memories and for building amazing tools and supporting ecosystems.

I'll still be around the CNCF world and hope to see you all around. Please don't hesitate to reach out if you need anything.

Sincerely,

Vic


Stepping down as an Org Maintainer

Vic Iglesias
 

Team,

I've been apart from the day to day of Helm, Charts and the rest of the ecosystem for a while now due to many factors but overwhelmingly because of the birth of my wonderful two boys over the last few years and my role change at Google to the PM organization.

My time working with you all has been some of the best I've experienced in my life. It was fulfilling, challenging and most of all extremely fun to be a part of this wonderful community of both developers and users.

Thank you for the memories and for building amazing tools and supporting ecosystems.

I'll still be around the CNCF world and hope to see you all around. Please don't hesitate to reach out if you need anything.

Sincerely,

Vic


[HIP] Dynamic Chart Dependency Overrides

David Mládek <david.mladek.cz@...>
 

Hello everyone,

Based on discussion in an issue I have decided to write up a HIP for allowing dependency overrides during helm install/update operations.

Details can be seen in the merge request linked below, but this would have to be aimed at Helm v4 because of feature dependency on actual consistent resolving of dependencies during install/update. Otherwise I believe this proposal to be fairly straightforward. Syntax would be similar to `--set`.

https://github.com/helm/community/pull/176

I would appreciate any feedback on this.

Best regards,
David Mládek


Re: jsonnet/tanka helm templating

Matt Fisher <matt.fisher@...>
 

Re-sending as a reply-all.

Hi Andrey,

Have you read through the threads on github? This particular discussion topic has been discussed at length.... Probably once every few months I'd say at least.

I'd highly suggest reading through some of those threads as it may influence many of the design discussions in your HIP.

To clear up some things: Helm 2 had a selectable engine interface since its inception. Chart.yaml provided an optional engine​ field. The Rudder gRPC API made it possible to implement a remote template renderer. But after 5 years of development and advocating it to many community members, nobody wrote an alternative template engine. The engine interface never saw any enhancements, changes, or refactors. So we removed it in Helm 3 as the code had gone stale, and the design did not fit into the new model with Tiller/Rudder being removed.

One primary concern with prior proposals was they did not provide a solution to the "one size fits all" problem. Some proposals argued that a chart could declare the need for an alternative template engine that does not exist in mainline Helm, relying on a "plugin" model to handle template rendering. That discussion led to further debate on how plugins could be resolved, how the API contract will fit in, how the user is expected to install the right rendering engine for their chart, etc.

Discussing your ideas in a HIP would be worthwhile, but I do want you to understand that this topic has been discussed in the past. I look forward to the proposal.

Matt


From: cncf-helm@... <cncf-helm@...> on behalf of Andrey Tuzhilin via lists.cncf.io <andrei.tuzhilin=gmail.com@...>
Sent: Wednesday, May 12, 2021 4:14 AM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] jsonnet/tanka helm templating
 
Hey!


I want to make a feature HIP to add jsonnet templating to helm. Specifically, I want helm to have tanka-like functionality with plugged kubernetes libs.

Motivation:
1. go templates have lots of well-knows drawbacks
2. adding "pluggable" engine will have very narrow scope: 
- general purpose charts would have to use go templates to stay portable
- you can’t add plugged-in (default) libraries for each and every engine, like tanka std library
3. jsonnet + libs solves two main helm templating problems:
- lots of boilerplate code (labels, annotations, name overrides etc.)
- hard to read error prone yaml + go templates syntax

What do you think?


Andrey


jsonnet/tanka helm templating

Andrey Tuzhilin <andrei.tuzhilin@...>
 

Hey!


I want to make a feature HIP to add jsonnet templating to helm. Specifically, I want helm to have tanka-like functionality with plugged kubernetes libs.

Motivation:
1. go templates have lots of well-knows drawbacks
2. adding "pluggable" engine will have very narrow scope: 
- general purpose charts would have to use go templates to stay portable
- you can’t add plugged-in (default) libraries for each and every engine, like tanka std library
3. jsonnet + libs solves two main helm templating problems:
- lots of boilerplate code (labels, annotations, name overrides etc.)
- hard to read error prone yaml + go templates syntax

What do you think?


Andrey


Re: How are people estimating efforts for developing and maintaining Helm chart based product releases?

Sandip Chitale
 

Hi Berin,

Thanks for your comprehensive response.

Best Reagrds,
Sandip


Re: How are people estimating efforts for developing and maintaining Helm chart based product releases?

Loritsch, Berin <bloritsch@...>
 

Helm definitely has some wrinkles, and I've run into a few.  So I would recommend separating your tasking.  For example:
  • Writing docker files and helm charts are separate activities, they deserve separate estimates
  • Design your helm chart--identify what needs to be externally configured to include it in a larger deployment?  That's a separate estimate that you might be able to apply the results across all your services (if you have a microservices environment)
  • Writing the chart itself--design for the fresh install scenario
  • Do your deployment testing
You do have to understand one thing: Helm templates kubernetes YAML files.  Helm owes its ability to upgrade in place to the underlying kubernetes infrastructure.  Kubernetes YAML files are declarative, not procedural.  In other words you declare what you need, not how to make it happen.  The helm command line will make sure the right calls are invoked to get your desired infrastructure, but it's Kubernetes doing the heavy lifting.  In theory fresh installs and upgrades don't look any different to a Kubernetes cluster.

You do need to test those scenarios, but they shouldn't be separate tasking.

Regarding CI/CD, I recommend you look into the various Continuous Deployment tools for Kubernetes clusters.  For example, FluxCD and/or ArgoCD both work with Helm and manage your configuration and deployment for your environment(s).  Your Continuous Integration platform of choice builds the different packages (containers and helm charts) and deploys them to your local repository (like Sonatype Nexus or JFrog Artifactory).  Your CD tool of choice pulls those new packages from that repository and updates your deployments as necessary.

It's a lot of moving parts, but each part does have a specific purpose.

On Wed, May 5, 2021 at 10:41 PM Sandip Chitale <sandipchitale@...> wrote:

This is a somewhat open ended question but I am looking for some real world, practical knowledge/experience about effort estimation for developing and maintaining Helm chart based products.

Helm3 is supposed to make deployment of applications to Kubernetes platform easy. The helm install/upgrade/rollback single commands to do the deployments on the surface make it sound easy. But this is slightly deceptive though. The actual process involves:

  • Development of
    • Docker files
    • Helm Charts
      • Fresh install use case
      • Upgrade use case
      • Evolution of values files from release to release
  • Automation of builds on CI
    • Build Docker images
    • Build Helm packages
  • Automation of testing with built Docker images using the helm chart
    • testing fresh installs
    • testing upgrade
      • implement backup before upgrade strategy
    • testing rollbacks
      • implement restore after rollback
  • Implementation of tag and helm chart versioning pre-test and for release
  • Build and prepare release artifacts for Docker images and Helm package
  • Supporting fresh installs
    • Documentation of the values files and process
  • Supporting upgrades
    • Documentation of the values files evolution for customers previous version of values files and process of backup, upgrade
    • Dealing with upgrade failures implement recovery using backup/restore and helm rollbacks

I am looking for information like what effort estimation/story points estimation  strategies people are using. 

Practically, how many people are working in your teams on the full development lifecycle discussed above. Of course this may vary from team to team and product to product. All aspects above may or may not apply to your projects.

I think how to estimate java, dotnet, frontend projects is relatively well as we have been developing those for some time.

Do you have any insights to share?


Thanks.



--
Berin Loritsch

DOMEX Architect


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708


How are people estimating efforts for developing and maintaining Helm chart based product releases?

Sandip Chitale
 

This is a somewhat open ended question but I am looking for some real world, practical knowledge/experience about effort estimation for developing and maintaining Helm chart based products.

Helm3 is supposed to make deployment of applications to Kubernetes platform easy. The helm install/upgrade/rollback single commands to do the deployments on the surface make it sound easy. But this is slightly deceptive though. The actual process involves:

  • Development of
    • Docker files
    • Helm Charts
      • Fresh install use case
      • Upgrade use case
      • Evolution of values files from release to release
  • Automation of builds on CI
    • Build Docker images
    • Build Helm packages
  • Automation of testing with built Docker images using the helm chart
    • testing fresh installs
    • testing upgrade
      • implement backup before upgrade strategy
    • testing rollbacks
      • implement restore after rollback
  • Implementation of tag and helm chart versioning pre-test and for release
  • Build and prepare release artifacts for Docker images and Helm package
  • Supporting fresh installs
    • Documentation of the values files and process
  • Supporting upgrades
    • Documentation of the values files evolution for customers previous version of values files and process of backup, upgrade
    • Dealing with upgrade failures implement recovery using backup/restore and helm rollbacks

I am looking for information like what effort estimation/story points estimation  strategies people are using. 

Practically, how many people are working in your teams on the full development lifecycle discussed above. Of course this may vary from team to team and product to product. All aspects above may or may not apply to your projects.

I think how to estimate java, dotnet, frontend projects is relatively well as we have been developing those for some time.

Do you have any insights to share?


Thanks.


Re: [HIP] helm lock

Paul Czarkowski
 

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.

 

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


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:

  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.

 

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


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


Re: [HIP] helm lock

Matt Fisher <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


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:
  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


Re: [HIP] helm lock

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.
--
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:
  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


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


[HIP] helm lock

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.

--
Justin Garrison
justingarrison.com


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
 

Hi Teja,

https://github.com/quintush/helm-unittest provides support for helm chart unit tests. Some alternatives are also listed in https://github.com/quintush/helm-unittest#related-projects--commands including https://blog.gruntwork.io/automated-testing-for-kubernetes-and-helm-charts-using-terratest-a4ddc4e67344 which provides a nice overview of one test pyramid using terratest for helm charts.

Hope this helps,

Guillaume.


Re: Pre-proposal idea: introduce a new flag for helm uninstall "--fail-on-error" and a new release status "failed-uninstall"

Joe Lanford
 

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

Rimas
 

JFrog https://Chartcenter.io services will be deprecated soon.

Please read more about it at https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

 


Why are dependencies embedded rather than resolved?

Loritsch, Berin <bloritsch@...>
 

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
 
Edited

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 <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.

 

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.

 

On Fri, Jan 15, 2021 at 5:57 PM Matt Butcher <Matt.Butcher@...> wrote:

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'.


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


 

--

Berin Loritsch

DOMEX Architect

7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708

81 - 100 of 454