Date   

Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Matt Fisher <matt.fisher@...>
 

> I thought following semver on the Go API for v3 was a given.

Absolutely. I'm specifically talking about the stability of pkg/registry, which is the package used primarily for communicating with OCI registries.

The question I'm wondering is "If we're marking certain features of the client as experimental, should the SDK receive the same treatment? If so, how?"

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of via Lists.Cncf.Io <jimmyzelinskie=gmail.com@...>
Sent: Tuesday, August 6, 2019 10:04 AM
To: Matt Farina <matt@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
 
>I think what Jimmy is suggesting fits in with the first option

Yup! I wasn't sure if the intent of the first option was to simply put the string `(experimental)` next to the usage and call it a day or not.

The Go compiler has been using environment variables for feature gating (e.g. GOMODULES111=on). Having to append `--experimental` to commands seems monotonous for those testing the functionality, although that might be desirable so that if anyone sees the bash history (or is shown the command) it's extremely clear that the work isn't stable.

On Tue, Aug 6, 2019 at 12:59 PM Matt Farina <matt@...> wrote:
I think what Jimmy is suggesting fits in with the first option of:

1) To document the feature as experimental in the CLI and in the documentation. Breaking changes may (likely?) happen to support the final implementation. It would not fall under Helms use of SemVer until it is no longer an experiment. We would likely not expose it via the usage information until it was ready.

In this case the usage would be hidden from the CLI until it's ready. I think we need to have it characterized as experimental and not following the SemVer guarantee so as not to confuse people who have used it. This way everyone is clear that could break and isn't following SemVer.

Do we hit it behind a flag of something like `--experimental`?

On Tue, Aug 6, 2019, at 11:54 AM, Matt Farina wrote:
FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...

----- Original message -----
To: Matt Farina <matt@...>
Subject: Private: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Date: Tuesday, August 06, 2019 11:49 AM

Hey there,

I'd like to propose a third option which is to continue the existing work, but hide it from the CLI usage by default. This will allow continued development, but without user confusion. I'd argue that even if you tell people that the functionality is experimental, it'll confuse people unless they have to explicitly opt in somehow (e.g. export an environment variable).

While pulling out into a plug-in is a noble goal, App Registry was stifled a lot by the limitations of the plug-in model, which only compounded the difficulty of getting feature functionality finished. I think getting core functionality implemented first should be the priority and then a later version of Helm could focus development on pulling out as many features as possible into plug-ins.



Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Jimmy Zelinskie <jimmyzelinskie@...>
 

>I think what Jimmy is suggesting fits in with the first option

Yup! I wasn't sure if the intent of the first option was to simply put the string `(experimental)` next to the usage and call it a day or not.

The Go compiler has been using environment variables for feature gating (e.g. GOMODULES111=on). Having to append `--experimental` to commands seems monotonous for those testing the functionality, although that might be desirable so that if anyone sees the bash history (or is shown the command) it's extremely clear that the work isn't stable.

On Tue, Aug 6, 2019 at 12:59 PM Matt Farina <matt@...> wrote:
I think what Jimmy is suggesting fits in with the first option of:

1) To document the feature as experimental in the CLI and in the documentation. Breaking changes may (likely?) happen to support the final implementation. It would not fall under Helms use of SemVer until it is no longer an experiment. We would likely not expose it via the usage information until it was ready.

In this case the usage would be hidden from the CLI until it's ready. I think we need to have it characterized as experimental and not following the SemVer guarantee so as not to confuse people who have used it. This way everyone is clear that could break and isn't following SemVer.

Do we hit it behind a flag of something like `--experimental`?

On Tue, Aug 6, 2019, at 11:54 AM, Matt Farina wrote:
FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...

----- Original message -----
To: Matt Farina <matt@...>
Subject: Private: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Date: Tuesday, August 06, 2019 11:49 AM

Hey there,

I'd like to propose a third option which is to continue the existing work, but hide it from the CLI usage by default. This will allow continued development, but without user confusion. I'd argue that even if you tell people that the functionality is experimental, it'll confuse people unless they have to explicitly opt in somehow (e.g. export an environment variable).

While pulling out into a plug-in is a noble goal, App Registry was stifled a lot by the limitations of the plug-in model, which only compounded the difficulty of getting feature functionality finished. I think getting core functionality implemented first should be the priority and then a later version of Helm could focus development on pulling out as many features as possible into plug-ins.



Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Josh Dolitsky
 

The feature gates approach sounds good to me. In general, I’m in favor of keeping the work in tree and marking experimental (vs. plugin).

@Matt when/where would the feature gates be configured? On “helm init”?

Thanks,

Josh

On Tue, Aug 6, 2019 at 12:20 PM Matt Fisher via Lists.Cncf.Io <matt.fisher=microsoft.com@...> wrote:
There are a few common practices for marking features as experimental:

  1. Setting a field in a config file, e.g. `experimental: true` that enables all features
  2. A feature gates model that enables a subset of experimental or alpha features. Very similar to the first point. `feature-gates: ["oci", "fancy-feature"]`
  3. Appending a prefix to the command, e.g. `helm experimental-registry ...`
  4. The plugin model
Here's a list of projects used in production today that map to each of these features:

  1. Docker CLI uses the --experimental flag: https://github.com/docker/docker-ce/blob/master/components/cli/experimental/README.md#use-docker-experimental
  2. Kubernetes uses the feature gates model: https://kubernetes.io/docs/reference/command-line-tools-reference/
  3. Cloud Foundry uses the prefixed model: https://docs.cloudfoundry.org/devguide/v3-commands.html
  4. Helm currently has a plugin model. It has been used in the past for experimental work, but as Jimmy pointed out, it has stifled work that was intended to be added to
Right now I'm leaning towards the feature gates model. It provides users an opportunity to enable only the features they want to test without needing to enable *everything*, which may potentially break their UX. In other words, users may want to test one experimental feature, but another experimental feature may break their workflow in another way.

If this sounds good to others, I'll start hacking on an implementation of the feature gates model and put the OCI work behind a feature gate. That way we can start playing with the idea to see if that's the model we want to move forward with.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Tuesday, August 6, 2019 9:59 AM
To: cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
 
I think what Jimmy is suggesting fits in with the first option of:

1) To document the feature as experimental in the CLI and in the documentation. Breaking changes may (likely?) happen to support the final implementation. It would not fall under Helms use of SemVer until it is no longer an experiment. We would likely not expose it via the usage information until it was ready.

In this case the usage would be hidden from the CLI until it's ready. I think we need to have it characterized as experimental and not following the SemVer guarantee so as not to confuse people who have used it. This way everyone is clear that could break and isn't following SemVer.

Do we hit it behind a flag of something like `--experimental`?

On Tue, Aug 6, 2019, at 11:54 AM, Matt Farina wrote:
FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...

----- Original message -----
To: Matt Farina <matt@...>
Subject: Private: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Date: Tuesday, August 06, 2019 11:49 AM

Hey there,

I'd like to propose a third option which is to continue the existing work, but hide it from the CLI usage by default. This will allow continued development, but without user confusion. I'd argue that even if you tell people that the functionality is experimental, it'll confuse people unless they have to explicitly opt in somehow (e.g. export an environment variable).

While pulling out into a plug-in is a noble goal, App Registry was stifled a lot by the limitations of the plug-in model, which only compounded the difficulty of getting feature functionality finished. I think getting core functionality implemented first should be the priority and then a later version of Helm could focus development on pulling out as many features as possible into plug-ins.



Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Matt Farina
 

I thought following semver on the Go API for v3 was a given. I think it's important with the way Go modules don't allow you to set a high end for the range resolution for minor versions. The tooling basically requires you to follow semver or you could break the importers experience.

If we go with feature gates I would suggest we do it as a flag or an environment variable. I can see myself setting the environment variable and using repeated commands.


On Tue, Aug 6, 2019, at 1:27 PM, Matt Fisher wrote:
The other aspect we may want to consider is the SDK. In Helm 2, we had a strict backwards compatibility contract for the Go SDK. Anything that was made public could not be changed from Helm 2.0.0 onwards. I'd like to continue that tradition when we release Helm 3.0.0 - users have appreciated the amount of effort we put into ensuring backwards compatibility, allowing them to build other projects on top of the SDK.

In Helm 3, we use a package called `internal` which is hidden from the public SDK's view. In other words, packages made available there cannot be consumed by SDK users.

What does everyone think of moving experimental feature work into that package? That way it's hidden from SDK users while we are working out the right design. Something like `internal/experimental/<name-of-package-goes-here>`.






1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada




From: cncf-helm@... <cncf-helm@...> on behalf of Matt Fisher via Lists.Cncf.Io <matt.fisher=microsoft.com@...>
Sent: Tuesday, August 6, 2019 10:20 AM
To: cncf-helm@... <cncf-helm@...>; matt@... <matt@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
 
There are a few common practices for marking features as experimental:

  1. Setting a field in a config file, e.g. `experimental: true` that enables all features
  2. A feature gates model that enables a subset of experimental or alpha features. Very similar to the first point. `feature-gates: ["oci", "fancy-feature"]`
  3. Appending a prefix to the command, e.g. `helm experimental-registry ...`
  4. The plugin model
Here's a list of projects used in production today that map to each of these features:

  1. Docker CLI uses the --experimental flag: https://github.com/docker/docker-ce/blob/master/components/cli/experimental/README.md#use-docker-experimental
  2. Kubernetes uses the feature gates model: https://kubernetes.io/docs/reference/command-line-tools-reference/
  3. Cloud Foundry uses the prefixed model: https://docs.cloudfoundry.org/devguide/v3-commands.html
  4. Helm currently has a plugin model. It has been used in the past for experimental work, but as Jimmy pointed out, it has stifled work that was intended to be added to
Right now I'm leaning towards the feature gates model. It provides users an opportunity to enable only the features they want to test without needing to enable *everything*, which may potentially break their UX. In other words, users may want to test one experimental feature, but another experimental feature may break their workflow in another way.

If this sounds good to others, I'll start hacking on an implementation of the feature gates model and put the OCI work behind a feature gate. That way we can start playing with the idea to see if that's the model we want to move forward with.






1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada




From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Tuesday, August 6, 2019 9:59 AM
To: cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
 
I think what Jimmy is suggesting fits in with the first option of:

1) To document the feature as experimental in the CLI and in the documentation. Breaking changes may (likely?) happen to support the final implementation. It would not fall under Helms use of SemVer until it is no longer an experiment. We would likely not expose it via the usage information until it was ready.

In this case the usage would be hidden from the CLI until it's ready. I think we need to have it characterized as experimental and not following the SemVer guarantee so as not to confuse people who have used it. This way everyone is clear that could break and isn't following SemVer.

Do we hit it behind a flag of something like `--experimental`?

On Tue, Aug 6, 2019, at 11:54 AM, Matt Farina wrote:
FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...

----- Original message -----
From: jimmyzelinskie+cncf@...
To: Matt Farina <matt@...>
Subject: Private: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Date: Tuesday, August 06, 2019 11:49 AM

Hey there,

I'd like to propose a third option which is to continue the existing work, but hide it from the CLI usage by default. This will allow continued development, but without user confusion. I'd argue that even if you tell people that the functionality is experimental, it'll confuse people unless they have to explicitly opt in somehow (e.g. export an environment variable).

While pulling out into a plug-in is a noble goal, App Registry was stifled a lot by the limitations of the plug-in model, which only compounded the difficulty of getting feature functionality finished. I think getting core functionality implemented first should be the priority and then a later version of Helm could focus development on pulling out as many features as possible into plug-ins.




Attachments:
  • Outlook-1504220459.png
  • Outlook-1504220459.png


Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Matt Fisher <matt.fisher@...>
 

The other aspect we may want to consider is the SDK. In Helm 2, we had a strict backwards compatibility contract for the Go SDK. Anything that was made public could not be changed from Helm 2.0.0 onwards. I'd like to continue that tradition when we release Helm 3.0.0 - users have appreciated the amount of effort we put into ensuring backwards compatibility, allowing them to build other projects on top of the SDK.

In Helm 3, we use a package called `internal` which is hidden from the public SDK's view. In other words, packages made available there cannot be consumed by SDK users.

What does everyone think of moving experimental feature work into that package? That way it's hidden from SDK users while we are working out the right design. Something like `internal/experimental/<name-of-package-goes-here>`.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of Matt Fisher via Lists.Cncf.Io <matt.fisher=microsoft.com@...>
Sent: Tuesday, August 6, 2019 10:20 AM
To: cncf-helm@... <cncf-helm@...>; matt@... <matt@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
 
There are a few common practices for marking features as experimental:

  1. Setting a field in a config file, e.g. `experimental: true` that enables all features
  2. A feature gates model that enables a subset of experimental or alpha features. Very similar to the first point. `feature-gates: ["oci", "fancy-feature"]`
  3. Appending a prefix to the command, e.g. `helm experimental-registry ...`
  4. The plugin model
Here's a list of projects used in production today that map to each of these features:

  1. Docker CLI uses the --experimental flag: https://github.com/docker/docker-ce/blob/master/components/cli/experimental/README.md#use-docker-experimental
  2. Kubernetes uses the feature gates model: https://kubernetes.io/docs/reference/command-line-tools-reference/
  3. Cloud Foundry uses the prefixed model: https://docs.cloudfoundry.org/devguide/v3-commands.html
  4. Helm currently has a plugin model. It has been used in the past for experimental work, but as Jimmy pointed out, it has stifled work that was intended to be added to
Right now I'm leaning towards the feature gates model. It provides users an opportunity to enable only the features they want to test without needing to enable *everything*, which may potentially break their UX. In other words, users may want to test one experimental feature, but another experimental feature may break their workflow in another way.

If this sounds good to others, I'll start hacking on an implementation of the feature gates model and put the OCI work behind a feature gate. That way we can start playing with the idea to see if that's the model we want to move forward with.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Tuesday, August 6, 2019 9:59 AM
To: cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
 
I think what Jimmy is suggesting fits in with the first option of:

1) To document the feature as experimental in the CLI and in the documentation. Breaking changes may (likely?) happen to support the final implementation. It would not fall under Helms use of SemVer until it is no longer an experiment. We would likely not expose it via the usage information until it was ready.

In this case the usage would be hidden from the CLI until it's ready. I think we need to have it characterized as experimental and not following the SemVer guarantee so as not to confuse people who have used it. This way everyone is clear that could break and isn't following SemVer.

Do we hit it behind a flag of something like `--experimental`?

On Tue, Aug 6, 2019, at 11:54 AM, Matt Farina wrote:
FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...

----- Original message -----
From: jimmyzelinskie+cncf@...
To: Matt Farina <matt@...>
Subject: Private: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Date: Tuesday, August 06, 2019 11:49 AM

Hey there,

I'd like to propose a third option which is to continue the existing work, but hide it from the CLI usage by default. This will allow continued development, but without user confusion. I'd argue that even if you tell people that the functionality is experimental, it'll confuse people unless they have to explicitly opt in somehow (e.g. export an environment variable).

While pulling out into a plug-in is a noble goal, App Registry was stifled a lot by the limitations of the plug-in model, which only compounded the difficulty of getting feature functionality finished. I think getting core functionality implemented first should be the priority and then a later version of Helm could focus development on pulling out as many features as possible into plug-ins.



Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Matt Fisher <matt.fisher@...>
 

There are a few common practices for marking features as experimental:

  1. Setting a field in a config file, e.g. `experimental: true` that enables all features
  2. A feature gates model that enables a subset of experimental or alpha features. Very similar to the first point. `feature-gates: ["oci", "fancy-feature"]`
  3. Appending a prefix to the command, e.g. `helm experimental-registry ...`
  4. The plugin model
Here's a list of projects used in production today that map to each of these features:

  1. Docker CLI uses the --experimental flag: https://github.com/docker/docker-ce/blob/master/components/cli/experimental/README.md#use-docker-experimental
  2. Kubernetes uses the feature gates model: https://kubernetes.io/docs/reference/command-line-tools-reference/
  3. Cloud Foundry uses the prefixed model: https://docs.cloudfoundry.org/devguide/v3-commands.html
  4. Helm currently has a plugin model. It has been used in the past for experimental work, but as Jimmy pointed out, it has stifled work that was intended to be added to
Right now I'm leaning towards the feature gates model. It provides users an opportunity to enable only the features they want to test without needing to enable *everything*, which may potentially break their UX. In other words, users may want to test one experimental feature, but another experimental feature may break their workflow in another way.

If this sounds good to others, I'll start hacking on an implementation of the feature gates model and put the OCI work behind a feature gate. That way we can start playing with the idea to see if that's the model we want to move forward with.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Tuesday, August 6, 2019 9:59 AM
To: cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
 
I think what Jimmy is suggesting fits in with the first option of:

1) To document the feature as experimental in the CLI and in the documentation. Breaking changes may (likely?) happen to support the final implementation. It would not fall under Helms use of SemVer until it is no longer an experiment. We would likely not expose it via the usage information until it was ready.

In this case the usage would be hidden from the CLI until it's ready. I think we need to have it characterized as experimental and not following the SemVer guarantee so as not to confuse people who have used it. This way everyone is clear that could break and isn't following SemVer.

Do we hit it behind a flag of something like `--experimental`?

On Tue, Aug 6, 2019, at 11:54 AM, Matt Farina wrote:
FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...

----- Original message -----
From: jimmyzelinskie+cncf@...
To: Matt Farina <matt@...>
Subject: Private: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Date: Tuesday, August 06, 2019 11:49 AM

Hey there,

I'd like to propose a third option which is to continue the existing work, but hide it from the CLI usage by default. This will allow continued development, but without user confusion. I'd argue that even if you tell people that the functionality is experimental, it'll confuse people unless they have to explicitly opt in somehow (e.g. export an environment variable).

While pulling out into a plug-in is a noble goal, App Registry was stifled a lot by the limitations of the plug-in model, which only compounded the difficulty of getting feature functionality finished. I think getting core functionality implemented first should be the priority and then a later version of Helm could focus development on pulling out as many features as possible into plug-ins.



Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Matt Farina
 

I think what Jimmy is suggesting fits in with the first option of:

1) To document the feature as experimental in the CLI and in the documentation. Breaking changes may (likely?) happen to support the final implementation. It would not fall under Helms use of SemVer until it is no longer an experiment. We would likely not expose it via the usage information until it was ready.

In this case the usage would be hidden from the CLI until it's ready. I think we need to have it characterized as experimental and not following the SemVer guarantee so as not to confuse people who have used it. This way everyone is clear that could break and isn't following SemVer.

Do we hit it behind a flag of something like `--experimental`?

On Tue, Aug 6, 2019, at 11:54 AM, Matt Farina wrote:
FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...

----- Original message -----
From: jimmyzelinskie+cncf@...
To: Matt Farina <matt@...>
Subject: Private: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Date: Tuesday, August 06, 2019 11:49 AM

Hey there,

I'd like to propose a third option which is to continue the existing work, but hide it from the CLI usage by default. This will allow continued development, but without user confusion. I'd argue that even if you tell people that the functionality is experimental, it'll confuse people unless they have to explicitly opt in somehow (e.g. export an environment variable).

While pulling out into a plug-in is a noble goal, App Registry was stifled a lot by the limitations of the plug-in model, which only compounded the difficulty of getting feature functionality finished. I think getting core functionality implemented first should be the priority and then a later version of Helm could focus development on pulling out as many features as possible into plug-ins.



Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Matt Farina
 

FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...

----- Original message -----
From: jimmyzelinskie+cncf@...
To: Matt Farina <matt@...>
Subject: Private: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Date: Tuesday, August 06, 2019 11:49 AM

Hey there,

I'd like to propose a third option which is to continue the existing work, but hide it from the CLI usage by default. This will allow continued development, but without user confusion. I'd argue that even if you tell people that the functionality is experimental, it'll confuse people unless they have to explicitly opt in somehow (e.g. export an environment variable).

While pulling out into a plug-in is a noble goal, App Registry was stifled a lot by the limitations of the plug-in model, which only compounded the difficulty of getting feature functionality finished. I think getting core functionality implemented first should be the priority and then a later version of Helm could focus development on pulling out as many features as possible into plug-ins.


How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Matt Farina
 

One of the features being developed for Helm v3 is the ability to store Helm charts in OCI container image repositories (by following the distribution spec). You can think of these as repositories like Docker Hub, Quay, Azure Container Registry, and others. But, the distribution spec was designed for images rather than other artifacts which some, including more than Helm, are trying to put in there now. Work has been ongoing with the OCI to work out the best way to store these artifacts but it isn't complete and won't be complete in time to push out the 3.0.0. We don't want to delay the 3.0.0 for this feature so we are looking for feedback on some of the options we have discussed.

The options we are looking at are:

1) To document the feature as experimental in the CLI and in the documentation. Breaking changes may (likely?) happen to support the final implementation. It would not fall under Helms use of SemVer until it is no longer an experiment. We would likely not expose it via the usage information until it was ready.

2) Move the OCI integration into a plugin that would need to be installed. It would be hosted under the Helm org on GitHub. Once it is ready it would be added to Helm v3 as part of a feature release.

Note, just because Helm would be able to push and pull charts from repositories does not mean all repositories will support it. Many public repositories white list the artifacts they will store. Until Helm is added to the white list it would not work. Some repositories are not following the distribution spec and may run into issues. As use grows we hope more repositories support charts.

If you have feedback on either of the two paths we would appreciate it.

Regards,
Matt Farina


Re: PSA: Helm v3 and the Stable repository

Matt Farina
 

As part of the OCI work I would expect the calls to things like `helm install` to work transparently to the user. This is for the UX.

On Fri, Aug 2, 2019, at 10:41 AM, Josh Dolitsky wrote:
Sure - I think what I'm getting at is on the client side we may need to determine whether the ref in question is a traditional .tgz or if hosted on a registry. Requesting a chart from registry is not a typical "wget" type request, it instead requests things at some /v2 endpoint

For example:

$ bin/helm chart pull localhost:5000/stable/wordpress:7.0.1 --debug
7.0.1: Pulling from localhost:5000/stable/wordpress
DEBU[0000] resolving
DEBU[0000] do request                                    request.headers="map[Accept:[application/vnd.docker.distribution.manifest.v2+json, application/vnd.docker.distribution.manifest.list.v2+json, application/vnd.oci.image.manifest.v1+json, application/vnd.oci.image.index.v1+json, *]]" request.method=HEAD url="http://localhost:5000/v2/stable/wordpress/manifests/7.0.1"
DEBU[0000] fetch response received                       response.headers="map[Content-Length:[715] Content-Type:[application/vnd.oci.image.manifest.v1+json] Date:[Fri, 02 Aug 2019 14:34:25 GMT] Docker-Content-Digest:[sha256:d04d4897b15893dc2929d3105c0118d3a30e11a4ed6aaebed429dae0e7e7d0a4] Docker-Distribution-Api-Version:[registry/2.0] Etag:[\"sha256:d04d4897b15893dc2929d3105c0118d3a30e11a4ed6aaebed429dae0e7e7d0a4\"] X-Content-Type-Options:[nosniff]]" status="200 OK" url="http://localhost:5000/v2/stable/wordpress/manifests/7.0.1"
DEBU[0000] resolved
Note: currently, "helm pull" / "helm fetch" do not yet support registry fetch, it is still sitting safely behind "helm chart pull":

$ bin/helm pull localhost:5000/stable/wordpress:7.0.1
Error: non-absolute URLs should be in form of repo_name/path_to_chart, got: localhost:5000/stable/wordpress:7.0.1

On Fri, Aug 2, 2019 at 6:53 AM Matt Farina <matt@...> wrote:

Josh,

What I suggested would require a redirect in monocular. I don't believe a change needs to happen in Helm unless there is a problem with it following redirects. The Helm CLI would not need to figure out when to redirect. This would be monocular doing something similar to the redirects to git that we get when using `go get`. Instead of a query string like `go get` uses we could do it based on the User Agent (see what's see in Helm here).

Once the Helm Hub speaks OCI (so it can list those) it would need to know to redirect differently for those. But, the same idea applies.

I don't think there would be a need for HEAD/GET setup.

- Matt

On Thu, Aug 1, 2019, at 5:48 PM, Josh Dolitsky wrote:
This is all great - just want to keep in mind how this will work alongside registry-based charts, where URL is always the ref being used.

Perhaps we have a HEAD/GET request to check to see if the url looks like a registry, otherwise fall back to this Hub lookup?

Josh

On Thu, Aug 1, 2019 at 4:11 PM Paul Czarkowski <pczarkowski@...> wrote:
Yeah I like that!  So if a "browser" identifies itself as the helm client and connects to a monocular URL, the repo software should give a 302 [temp] redirect to the tarball of the latest version.

example `helm install https://hub.helm.sh/charts/bitnami/rabbitmq` would go to hub, and hub would 302 it to https://charts.bitnami.com/bitnami/rabbitmq-6.2.3.tgz 

as long as monocular knows the remote repo, the chart name (in the url) and the current version (it knows these, as it displays the versions in hub.helm ).   

You might even allow `helm install https://hub.helm.sh/charts/bitnami/rabbitmq/6.2.3` as a way for them to provide a version, but that might be scope creeping a bit.

On Thu, Aug 1, 2019 at 2:48 PM Matt Fisher <Matt.Fisher@...> wrote:
That would be a great approach! It wouldn't be too difficult for monocular to handle those requests and redirect them accordingly to the right .tgz.

It would probably need to support https://helm.sh/prydonius/wordpress.prov so the --sign flag works with that workflow as well. That would be a really nice transition from the stable charts repo to Helm Hub, though.






1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada




From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Thursday, August 1, 2019 12:10 PM
To: Adnan Abdulhussein <aadnan@...>; Czarkowski-Golejewski, Paul (Pivotal) <pczarkowski@...>; cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] PSA: Helm v3 and the Stable repository
 
The timing for this is good. I wonder if Monocular (the software that powers the helm hub) could intercept a call to it based on the client and perform a redirect to the right package file. This could work for Helm v2 as well since `helm install <url to tgz>` works today.

What do y'all think about that?

On Wed, Jul 31, 2019, at 1:16 PM, Adnan Abdulhussein wrote:
Completely agree, I previously brought up the idea of using some sort of vanity URL to make it easier to install charts listed on the Helm Hub (https://github.com/helm/community/pull/24#issuecomment-395235744). For example, allowing users to do `helm install helm.sh/prydonius/wordpress`. The Helm install command could then automatically add the repository and install the chart (similar to how Homebrew works with taps).
On Jul 30, 2019, 2:52 PM -0700, via Lists.Cncf.Io <pczarkowski=pivotal.io@...>, wrote:

While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.

I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.

On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:

Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.

This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.

With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.









Attachments:
  • Outlook-1504220459.png


Attachments:
  • Outlook-1504220459.png


Re: PSA: Helm v3 and the Stable repository

Josh Dolitsky
 

Sure - I think what I'm getting at is on the client side we may need to determine whether the ref in question is a traditional .tgz or if hosted on a registry. Requesting a chart from registry is not a typical "wget" type request, it instead requests things at some /v2 endpoint

For example:

$ bin/helm chart pull localhost:5000/stable/wordpress:7.0.1 --debug
7.0.1: Pulling from localhost:5000/stable/wordpress
DEBU[0000] resolving
DEBU[0000] do request                                    request.headers="map[Accept:[application/vnd.docker.distribution.manifest.v2+json, application/vnd.docker.distribution.manifest.list.v2+json, application/vnd.oci.image.manifest.v1+json, application/vnd.oci.image.index.v1+json, *]]" request.method=HEAD url="http://localhost:5000/v2/stable/wordpress/manifests/7.0.1"
DEBU[0000] fetch response received                       response.headers="map[Content-Length:[715] Content-Type:[application/vnd.oci.image.manifest.v1+json] Date:[Fri, 02 Aug 2019 14:34:25 GMT] Docker-Content-Digest:[sha256:d04d4897b15893dc2929d3105c0118d3a30e11a4ed6aaebed429dae0e7e7d0a4] Docker-Distribution-Api-Version:[registry/2.0] Etag:[\"sha256:d04d4897b15893dc2929d3105c0118d3a30e11a4ed6aaebed429dae0e7e7d0a4\"] X-Content-Type-Options:[nosniff]]" status="200 OK" url="http://localhost:5000/v2/stable/wordpress/manifests/7.0.1"
DEBU[0000] resolved

Note: currently, "helm pull" / "helm fetch" do not yet support registry fetch, it is still sitting safely behind "helm chart pull":

$ bin/helm pull localhost:5000/stable/wordpress:7.0.1
Error: non-absolute URLs should be in form of repo_name/path_to_chart, got: localhost:5000/stable/wordpress:7.0.1

On Fri, Aug 2, 2019 at 6:53 AM Matt Farina <matt@...> wrote:
Josh,

What I suggested would require a redirect in monocular. I don't believe a change needs to happen in Helm unless there is a problem with it following redirects. The Helm CLI would not need to figure out when to redirect. This would be monocular doing something similar to the redirects to git that we get when using `go get`. Instead of a query string like `go get` uses we could do it based on the User Agent (see what's see in Helm here).

Once the Helm Hub speaks OCI (so it can list those) it would need to know to redirect differently for those. But, the same idea applies.

I don't think there would be a need for HEAD/GET setup.

- Matt

On Thu, Aug 1, 2019, at 5:48 PM, Josh Dolitsky wrote:
This is all great - just want to keep in mind how this will work alongside registry-based charts, where URL is always the ref being used.

Perhaps we have a HEAD/GET request to check to see if the url looks like a registry, otherwise fall back to this Hub lookup?

Josh

On Thu, Aug 1, 2019 at 4:11 PM Paul Czarkowski <pczarkowski@...> wrote:
Yeah I like that!  So if a "browser" identifies itself as the helm client and connects to a monocular URL, the repo software should give a 302 [temp] redirect to the tarball of the latest version.

example `helm install https://hub.helm.sh/charts/bitnami/rabbitmq` would go to hub, and hub would 302 it to https://charts.bitnami.com/bitnami/rabbitmq-6.2.3.tgz 

as long as monocular knows the remote repo, the chart name (in the url) and the current version (it knows these, as it displays the versions in hub.helm ).   

You might even allow `helm install https://hub.helm.sh/charts/bitnami/rabbitmq/6.2.3` as a way for them to provide a version, but that might be scope creeping a bit.

On Thu, Aug 1, 2019 at 2:48 PM Matt Fisher <Matt.Fisher@...> wrote:
That would be a great approach! It wouldn't be too difficult for monocular to handle those requests and redirect them accordingly to the right .tgz.

It would probably need to support https://helm.sh/prydonius/wordpress.prov so the --sign flag works with that workflow as well. That would be a really nice transition from the stable charts repo to Helm Hub, though.






1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada




From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Thursday, August 1, 2019 12:10 PM
To: Adnan Abdulhussein <aadnan@...>; Czarkowski-Golejewski, Paul (Pivotal) <pczarkowski@...>; cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] PSA: Helm v3 and the Stable repository
 
The timing for this is good. I wonder if Monocular (the software that powers the helm hub) could intercept a call to it based on the client and perform a redirect to the right package file. This could work for Helm v2 as well since `helm install <url to tgz>` works today.

What do y'all think about that?

On Wed, Jul 31, 2019, at 1:16 PM, Adnan Abdulhussein wrote:
Completely agree, I previously brought up the idea of using some sort of vanity URL to make it easier to install charts listed on the Helm Hub (https://github.com/helm/community/pull/24#issuecomment-395235744). For example, allowing users to do `helm install helm.sh/prydonius/wordpress`. The Helm install command could then automatically add the repository and install the chart (similar to how Homebrew works with taps).
On Jul 30, 2019, 2:52 PM -0700, via Lists.Cncf.Io <pczarkowski=pivotal.io@...>, wrote:

While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.

I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.

On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:

Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.

This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.

With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.









Attachments:
  • Outlook-1504220459.png


Re: PSA: Helm v3 and the Stable repository

Matt Farina
 

Josh,

What I suggested would require a redirect in monocular. I don't believe a change needs to happen in Helm unless there is a problem with it following redirects. The Helm CLI would not need to figure out when to redirect. This would be monocular doing something similar to the redirects to git that we get when using `go get`. Instead of a query string like `go get` uses we could do it based on the User Agent (see what's see in Helm here).

Once the Helm Hub speaks OCI (so it can list those) it would need to know to redirect differently for those. But, the same idea applies.

I don't think there would be a need for HEAD/GET setup.

- Matt

On Thu, Aug 1, 2019, at 5:48 PM, Josh Dolitsky wrote:
This is all great - just want to keep in mind how this will work alongside registry-based charts, where URL is always the ref being used.

Perhaps we have a HEAD/GET request to check to see if the url looks like a registry, otherwise fall back to this Hub lookup?

Josh

On Thu, Aug 1, 2019 at 4:11 PM Paul Czarkowski <pczarkowski@...> wrote:
Yeah I like that!  So if a "browser" identifies itself as the helm client and connects to a monocular URL, the repo software should give a 302 [temp] redirect to the tarball of the latest version.

example `helm install https://hub.helm.sh/charts/bitnami/rabbitmq` would go to hub, and hub would 302 it to https://charts.bitnami.com/bitnami/rabbitmq-6.2.3.tgz 

as long as monocular knows the remote repo, the chart name (in the url) and the current version (it knows these, as it displays the versions in hub.helm ).   

You might even allow `helm install https://hub.helm.sh/charts/bitnami/rabbitmq/6.2.3` as a way for them to provide a version, but that might be scope creeping a bit.

On Thu, Aug 1, 2019 at 2:48 PM Matt Fisher <Matt.Fisher@...> wrote:
That would be a great approach! It wouldn't be too difficult for monocular to handle those requests and redirect them accordingly to the right .tgz.

It would probably need to support https://helm.sh/prydonius/wordpress.prov so the --sign flag works with that workflow as well. That would be a really nice transition from the stable charts repo to Helm Hub, though.






1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada




From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Thursday, August 1, 2019 12:10 PM
To: Adnan Abdulhussein <aadnan@...>; Czarkowski-Golejewski, Paul (Pivotal) <pczarkowski@...>; cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] PSA: Helm v3 and the Stable repository
 
The timing for this is good. I wonder if Monocular (the software that powers the helm hub) could intercept a call to it based on the client and perform a redirect to the right package file. This could work for Helm v2 as well since `helm install <url to tgz>` works today.

What do y'all think about that?

On Wed, Jul 31, 2019, at 1:16 PM, Adnan Abdulhussein wrote:
Completely agree, I previously brought up the idea of using some sort of vanity URL to make it easier to install charts listed on the Helm Hub (https://github.com/helm/community/pull/24#issuecomment-395235744). For example, allowing users to do `helm install helm.sh/prydonius/wordpress`. The Helm install command could then automatically add the repository and install the chart (similar to how Homebrew works with taps).
On Jul 30, 2019, 2:52 PM -0700, via Lists.Cncf.Io <pczarkowski=pivotal.io@...>, wrote:

While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.

I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.

On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:

Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.

This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.

With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.









Attachments:
  • Outlook-1504220459.png


Re: PSA: Helm v3 and the Stable repository

Martin Hickey
 

+1

----- Original message -----
From: "Matt Farina" <matt@...>
Sent by: cncf-helm@...
To: "Adnan Abdulhussein" <aadnan@...>, "Czarkowski-Golejewski, Paul (Pivotal)" <pczarkowski@...>, "cncf-helm@..." <cncf-helm@...>
Cc:
Subject: [EXTERNAL] Re: [cncf-helm] PSA: Helm v3 and the Stable repository
Date: Thu, Aug 1, 2019 8:10 PM
 
The timing for this is good. I wonder if Monocular (the software that powers the helm hub) could intercept a call to it based on the client and perform a redirect to the right package file. This could work for Helm v2 as well since `helm install <url to tgz>` works today.
 
What do y'all think about that?
 
On Wed, Jul 31, 2019, at 1:16 PM, Adnan Abdulhussein wrote:
Completely agree, I previously brought up the idea of using some sort of vanity URL to make it easier to install charts listed on the Helm Hub (https://github.com/helm/community/pull/24#issuecomment-395235744). For example, allowing users to do `helm install helm.sh/prydonius/wordpress`. The Helm install command could then automatically add the repository and install the chart (similar to how Homebrew works with taps).
On Jul 30, 2019, 2:52 PM -0700, via Lists.Cncf.Io <pczarkowski=pivotal.io@...>, wrote:
 
While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.
 
I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.
 
On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:
 
Great question. Two things come to mind.
 
1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.
 
2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.
 
Does that help?
 
On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?
 
Thanks,
Kevin

From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository
 
When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.
 
This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.
 
With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.
 

 

 

 
 


Re: PSA: Helm v3 and the Stable repository

Josh Dolitsky
 

This is all great - just want to keep in mind how this will work alongside registry-based charts, where URL is always the ref being used.

Perhaps we have a HEAD/GET request to check to see if the url looks like a registry, otherwise fall back to this Hub lookup?

Josh

On Thu, Aug 1, 2019 at 4:11 PM Paul Czarkowski <pczarkowski@...> wrote:
Yeah I like that!  So if a "browser" identifies itself as the helm client and connects to a monocular URL, the repo software should give a 302 [temp] redirect to the tarball of the latest version.

example `helm install https://hub.helm.sh/charts/bitnami/rabbitmq` would go to hub, and hub would 302 it to https://charts.bitnami.com/bitnami/rabbitmq-6.2.3.tgz 

as long as monocular knows the remote repo, the chart name (in the url) and the current version (it knows these, as it displays the versions in hub.helm ).   

You might even allow `helm install https://hub.helm.sh/charts/bitnami/rabbitmq/6.2.3` as a way for them to provide a version, but that might be scope creeping a bit.

On Thu, Aug 1, 2019 at 2:48 PM Matt Fisher <Matt.Fisher@...> wrote:
That would be a great approach! It wouldn't be too difficult for monocular to handle those requests and redirect them accordingly to the right .tgz.

It would probably need to support https://helm.sh/prydonius/wordpress.prov so the --sign flag works with that workflow as well. That would be a really nice transition from the stable charts repo to Helm Hub, though.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Thursday, August 1, 2019 12:10 PM
To: Adnan Abdulhussein <aadnan@...>; Czarkowski-Golejewski, Paul (Pivotal) <pczarkowski@...>; cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] PSA: Helm v3 and the Stable repository
 
The timing for this is good. I wonder if Monocular (the software that powers the helm hub) could intercept a call to it based on the client and perform a redirect to the right package file. This could work for Helm v2 as well since `helm install <url to tgz>` works today.

What do y'all think about that?

On Wed, Jul 31, 2019, at 1:16 PM, Adnan Abdulhussein wrote:
Completely agree, I previously brought up the idea of using some sort of vanity URL to make it easier to install charts listed on the Helm Hub (https://github.com/helm/community/pull/24#issuecomment-395235744). For example, allowing users to do `helm install helm.sh/prydonius/wordpress`. The Helm install command could then automatically add the repository and install the chart (similar to how Homebrew works with taps).
On Jul 30, 2019, 2:52 PM -0700, via Lists.Cncf.Io <pczarkowski=pivotal.io@...>, wrote:

While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.

I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.

On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:

Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.

This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.

With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.





Re: PSA: Helm v3 and the Stable repository

Paul Czarkowski <pczarkowski@...>
 

Yeah I like that!  So if a "browser" identifies itself as the helm client and connects to a monocular URL, the repo software should give a 302 [temp] redirect to the tarball of the latest version.

example `helm install https://hub.helm.sh/charts/bitnami/rabbitmq` would go to hub, and hub would 302 it to https://charts.bitnami.com/bitnami/rabbitmq-6.2.3.tgz 

as long as monocular knows the remote repo, the chart name (in the url) and the current version (it knows these, as it displays the versions in hub.helm ).   

You might even allow `helm install https://hub.helm.sh/charts/bitnami/rabbitmq/6.2.3` as a way for them to provide a version, but that might be scope creeping a bit.

On Thu, Aug 1, 2019 at 2:48 PM Matt Fisher <Matt.Fisher@...> wrote:
That would be a great approach! It wouldn't be too difficult for monocular to handle those requests and redirect them accordingly to the right .tgz.

It would probably need to support https://helm.sh/prydonius/wordpress.prov so the --sign flag works with that workflow as well. That would be a really nice transition from the stable charts repo to Helm Hub, though.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Thursday, August 1, 2019 12:10 PM
To: Adnan Abdulhussein <aadnan@...>; Czarkowski-Golejewski, Paul (Pivotal) <pczarkowski@...>; cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] PSA: Helm v3 and the Stable repository
 
The timing for this is good. I wonder if Monocular (the software that powers the helm hub) could intercept a call to it based on the client and perform a redirect to the right package file. This could work for Helm v2 as well since `helm install <url to tgz>` works today.

What do y'all think about that?

On Wed, Jul 31, 2019, at 1:16 PM, Adnan Abdulhussein wrote:
Completely agree, I previously brought up the idea of using some sort of vanity URL to make it easier to install charts listed on the Helm Hub (https://github.com/helm/community/pull/24#issuecomment-395235744). For example, allowing users to do `helm install helm.sh/prydonius/wordpress`. The Helm install command could then automatically add the repository and install the chart (similar to how Homebrew works with taps).
On Jul 30, 2019, 2:52 PM -0700, via Lists.Cncf.Io <pczarkowski=pivotal.io@...>, wrote:

While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.

I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.

On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:

Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.

This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.

With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.





Re: PSA: Helm v3 and the Stable repository

Matt Fisher <matt.fisher@...>
 

That would be a great approach! It wouldn't be too difficult for monocular to handle those requests and redirect them accordingly to the right .tgz.

It would probably need to support https://helm.sh/prydonius/wordpress.prov so the --sign flag works with that workflow as well. That would be a really nice transition from the stable charts repo to Helm Hub, though.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Thursday, August 1, 2019 12:10 PM
To: Adnan Abdulhussein <aadnan@...>; Czarkowski-Golejewski, Paul (Pivotal) <pczarkowski@...>; cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] PSA: Helm v3 and the Stable repository
 
The timing for this is good. I wonder if Monocular (the software that powers the helm hub) could intercept a call to it based on the client and perform a redirect to the right package file. This could work for Helm v2 as well since `helm install <url to tgz>` works today.

What do y'all think about that?

On Wed, Jul 31, 2019, at 1:16 PM, Adnan Abdulhussein wrote:
Completely agree, I previously brought up the idea of using some sort of vanity URL to make it easier to install charts listed on the Helm Hub (https://github.com/helm/community/pull/24#issuecomment-395235744). For example, allowing users to do `helm install helm.sh/prydonius/wordpress`. The Helm install command could then automatically add the repository and install the chart (similar to how Homebrew works with taps).
On Jul 30, 2019, 2:52 PM -0700, via Lists.Cncf.Io <pczarkowski=pivotal.io@...>, wrote:

While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.

I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.

On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:

Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.

This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.

With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.





Proposal on Helm v2 support post v3.0.0 stable release

Matt Farina
 

We are currently discussing the support proposal for Helm v2 once Helm v3 is released. There are two reasons for this:

  1. We want to have a shared understanding about levels of support over time so there is no guessing. This will help people plan
  2. The tiller and legacy locations for downloading Helm v2 are in Google Cloud buckets owned and managed by Google rather than the CNCF (Helm had this before there was a CNCF). They will be removed at some point. There isn't a manner to move buckets to other projects. The URLs for some things (e.g., tiller and the stable repository) are hard coded into Helm. And, there are many people using older versions of Helm v2 so updates now will not completely solve the problem for users.

With that in mind, there is a proposal for a support period whose start is triggered by the release of Helm v3.0.0 documented at https://github.com/helm/helm/issues/6144.

Once we have the final decided support cycle I will share that here. If you have feedback on it please share. We are looking for input.

Regards,
Matt Farina


Re: PSA: Helm v3 and the Stable repository

Matt Farina
 

The timing for this is good. I wonder if Monocular (the software that powers the helm hub) could intercept a call to it based on the client and perform a redirect to the right package file. This could work for Helm v2 as well since `helm install <url to tgz>` works today.

What do y'all think about that?

On Wed, Jul 31, 2019, at 1:16 PM, Adnan Abdulhussein wrote:
Completely agree, I previously brought up the idea of using some sort of vanity URL to make it easier to install charts listed on the Helm Hub (https://github.com/helm/community/pull/24#issuecomment-395235744). For example, allowing users to do `helm install helm.sh/prydonius/wordpress`. The Helm install command could then automatically add the repository and install the chart (similar to how Homebrew works with taps).
On Jul 30, 2019, 2:52 PM -0700, via Lists.Cncf.Io <pczarkowski=pivotal.io@...>, wrote:

While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.

I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.

On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:

Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.

This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.

With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.





Re: PSA: Helm v3 and the Stable repository

Adnan Abdulhussein
 

Completely agree, I previously brought up the idea of using some sort of vanity URL to make it easier to install charts listed on the Helm Hub (https://github.com/helm/community/pull/24#issuecomment-395235744). For example, allowing users to do `helm install helm.sh/prydonius/wordpress`. The Helm install command could then automatically add the repository and install the chart (similar to how Homebrew works with taps).

On Jul 30, 2019, 2:52 PM -0700, via Lists.Cncf.Io <pczarkowski=pivotal.io@...>, wrote:
While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.

I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.

On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:
Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.

This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.

With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.


Re: PSA: Helm v3 and the Stable repository

Paul Czarkowski <pczarkowski@...>
 

While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.

I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.

On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:
Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.

This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.

With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.

241 - 260 of 457