cncf-helm@lists.cncf.io

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

Show quoted text

From: Justin Garrison <justinleegarrison@...>
Sent: Monday, March 1, 2021 1:02 PM
To: Matt Fisher <Matt.Fisher@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] [HIP] helm lock

Thanks for the link to the PR. That seems a bit different than what I had in mind.

Those are great questions to include in the proposal. Here's some basic answers and a question for clarification.

How would this prevent users from manually editing/updating resources underneath the chart using kubectl, kustomize, etc? Is this considered in-scope or out-of-scope? This is out of scope for locking. Charts should be explicit about what versions of dependencies they need and if a dependency cannot be met the upgrade should fail (same way apt and yum work). If I lock a yum package that requires a specific version of glibc yum will prevent me from upgrading glibc based on explicit version dependencies.
How would other tools like Helmfile interact with this feature? How can other tools use this feature? What happens if they don't? Maybe I don't know enough about how Helmfile's work but I thought it called `helm` based on the specification in the file. Native version locking would still prevent upgrades so no changes should be needed to Helmfiles.
Where do I find out which packages are marked as "held" or "unheld"? It would be great to have a `list` command like apt and yum but the lock information could also be displayed as part of other helm list commands
If I lock `nginx-ingress-vX.X.X`, does that apply to only one release, one namespace, or cluster-wide? Can I apply this lock across different scopes? A lock should be only per deployed chart. In helm 3 those are namespace scoped but you can also have some charts deployed multiple times under different names so a lock should only apply to one of them. This is probably the biggest difference between apt/yum because those work at a machine level but helm can have multiple versions of the same chart installed.
How does the locking mechanism work? If I lock to kubernetes/nginx-ingress-vX.X.X but I call `helm upgrade my-ingress bitnami/nginx-ingress-vX.X.X`, what happens? What happens if I replace it with a different chart (e.g. apache)? I wasn't aware you could do that. Is it common practice for someone to replace a chart for an in place deployment? I had assumed a chart could not be changed after it was deployed. If people do this and have a lock in place then there are unknown results. I suppose it would be the same if I had 2 repos on linux that both provided an nginx package and they both had different version strings. It would be up to me as an admin to know the difference and lock the correct version.

--
Justin Garrison
justingarrison.com

On Thu, Feb 25, 2021 at 2:23 PM Matt Fisher <Matt.Fisher@...> wrote:

Hey Justin!

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

In your proposal, it might be worth answering questions such as:

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

Hope this helps.

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

From: cncf-helm@... <cncf-helm@...> on behalf of Justin Garrison via lists.cncf.io <justinleegarrison=gmail.com@...>
Sent: Wednesday, February 24, 2021 5:21 PM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] [HIP] helm lock

I would like to propose a process to "lock" a helm release to a specific version so it is safe from `helm upgrade` and other situations that may cause unintended breaking changes.

There are a variety of ways to prevent breaking users with helm charts. Here are a couple I've investigated but both have limits.

Publish charts to different repos. This adds a lot of burden on the publisher to make sure all compatible versions are in a specific repo and users have to switch repos to upgrade.
Use deprecation messages to require user action before upgrading.

These methods should still be used if the maintainer wants to make sure user upgrades are safe, but it would also be good for consumers of the chart to not accidentally upgrade charts. There may be cases where a repo has stable and unstable versions. In that case it would be best if the user can "lock" their version to a stable release.

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

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

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

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

--
Justin Garrison
justingarrison.com

Re: [HIP] helm lock

Justin Garrison <justinleegarrison@...>

#367

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

Show quoted text

On Thu, Feb 25, 2021 at 2:23 PM Matt Fisher <Matt.Fisher@...> wrote:

Hey Justin!

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

In your proposal, it might be worth answering questions such as:

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

Hope this helps.

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

From: cncf-helm@... <cncf-helm@...> on behalf of Justin Garrison via lists.cncf.io <justinleegarrison=gmail.com@...>
Sent: Wednesday, February 24, 2021 5:21 PM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] [HIP] helm lock

I would like to propose a process to "lock" a helm release to a specific version so it is safe from `helm upgrade` and other situations that may cause unintended breaking changes.

There are a variety of ways to prevent breaking users with helm charts. Here are a couple I've investigated but both have limits.

Publish charts to different repos. This adds a lot of burden on the publisher to make sure all compatible versions are in a specific repo and users have to switch repos to upgrade.
Use deprecation messages to require user action before upgrading.

These methods should still be used if the maintainer wants to make sure user upgrades are safe, but it would also be good for consumers of the chart to not accidentally upgrade charts. There may be cases where a repo has stable and unstable versions. In that case it would be best if the user can "lock" their version to a stable release.

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

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

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

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

--
Justin Garrison
justingarrison.com

Re: [HIP] helm lock

Matt Fisher <matt.fisher@...>

#366

Hey Justin!

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

In your proposal, it might be worth answering questions such as:

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

Hope this helps.

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

Show 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
justingarrison.com

[HIP] helm lock

Justin Garrison <justinleegarrison@...>

#365

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

#364

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

#363

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

#362

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

#361

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

Why are dependencies embedded rather than resolved?

Loritsch, Berin <bloritsch@...>

#360

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

#359
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@...>

#358

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.

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

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

Re: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints

Loritsch, Berin <bloritsch@...>

#357

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.

Show quoted text

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

Re: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints

Matt Butcher <matt.butcher@...>

#356

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

Show 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

Loritsch, Berin <bloritsch@...>

#355

Sorry, wrong email.

Show quoted text

On Fri, Jan 15, 2021 at 4:46 PM Loritsch, Berin via lists.cncf.io <bloritsch=novetta.com@...> wrote:

Would 2pm work for you on monday?

On Fri, Jan 15, 2021 at 2:54 PM Paul Czarkowski <pczarkowski@...> wrote:

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.

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.

--

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

--

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

Loritsch, Berin <bloritsch@...>

#354

Would 2pm work for you on monday?

Show quoted text

On Fri, Jan 15, 2021 at 2:54 PM Paul Czarkowski <pczarkowski@...> wrote:

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.

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.

--

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: Is there any way to enforce constraints

Paul Czarkowski

#353

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.

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

--

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

Loritsch, Berin <bloritsch@...>

#352

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.

Show quoted text

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"

mikeshngdev@...

#351

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

#350

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, 2021

3.6 final release: Wednesday May 26th, 2021

Thanks

Show quoted text

On Thu, Jan 7, 2021 at 13:27 Marc Khouzam <marc.khouzam@...> wrote:

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

Marc

Is there any way to enforce constraints

Loritsch, Berin <bloritsch@...>

#349

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