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