|
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:
- Setting a field in a config file, e.g. `experimental: true` that enables all features
- A feature gates model that enables a subset of experimental or alpha features. Very similar to the first point. `feature-gates: ["oci", "fancy-feature"]`
- Appending a prefix to the command, e.g. `helm experimental-registry ...`
- The plugin model
Here's a list of projects used in production today that map to each of these features:
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
toggle quoted message
Show quoted text
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
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
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
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
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
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.
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 ).
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.
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
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:
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
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:
Attachments:
|
|
|
Re: PSA: Helm v3 and the Stable repository
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.1On 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
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.
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 ).
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.
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
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:
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
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:
|
|
|
Re: PSA: Helm v3 and the Stable repository
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
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.
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 ).
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.
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
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:
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
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:
|
|
|
Re: PSA: Helm v3 and the Stable repository
toggle quoted message
Show quoted text
----- 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
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
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
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.
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 ).
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.
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
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:
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
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.
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 ).
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.
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
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:
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
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.
Matthew Fisher
Caffeinated Software Engineer
Microsoft Canada
toggle quoted message
Show quoted text
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
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
We are currently discussing the support proposal for Helm v2 once Helm v3 is released. There are two reasons for this:
- We want to have a shared understanding about levels of support over time so there is no guessing. This will help people plan
- 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.
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
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
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
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:
toggle quoted message
Show quoted text
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
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
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.
|
|
|
Paul Czarkowski <pczarkowski@...>
Welcome to the Helm Community!
I recently took my friend JJ through getting started with Helm and he streamed it to twitch and then uploaded to youtube. If you want to watch us go from zero to hosting our own helm repo in about 3 hours ( can watch at 1.5x and skip bits ) it would probably teach you a lot.
hello ,
need some resources to learn helm ,please help me.
thank you!
|
|
|
Re: PSA: Helm v3 and the Stable repository
Fox, Kevin M <Kevin.Fox@...>
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?
Thanks,
Kevin
toggle quoted message
Show quoted text
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
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.
|
|
|
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.
|
|
|
Hi,
Welcome to Helm.
Documentation is a good place to start. The current release is Helm v2 and the documentation is at: https://helm.sh/docs/.
----- Original message -----
From: veereshreddy.r@...
Sent by: cncf-helm@...
To: cncf-helm@...
Cc:
Subject: [EXTERNAL] [cncf-helm] help to learn
Date: Tue, Jul 30, 2019 9:37 AM
hello ,
need some resources to learn helm ,please help me.
thank you!
|
|
|
