Topics

PSA: Helm v3 and the Stable repository

Matt Farina
 

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.

Matt Farina
 

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.

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


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.

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.

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.

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.




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.




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.




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.




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.
 

 

 

 
 

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

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

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