Hi All, I was advised to ask here regarding complex helm chart development. I'm trying to put together a new flight simulation system and this means a lot of inter-node communication through things

Hello everyone, i want to introduce a new project https://github.com/alauda/captain related to Helm3. It’s a controller based on the helm3 code, and defines several CRDs (HelmRequest, Release,

An environment variable seems to be the right approach. Either that or a config file similar to Docker's config.json. Matthew Fisher Caffeinated Software Engineer Microsoft Canada

> I thought following semver on the Go API for v3 was a given. Absolutely. I'm specifically talking about the stability of pkg/registry, which is the package used primarily for communicating with OCI

>I think what Jimmy is suggesting fits in with the first option Yup! I wasn't sure if the intent of the first option was to simply put the string `(experimental)` next to the usage and call it a day

The feature gates approach sounds good to me. In general, I’m in favor of keeping the work in tree and marking experimental (vs. plugin). @Matt when/where would the feature gates be configured? On

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

The other aspect we may want to consider is the SDK. In Helm 2, we had a strict backwards compatibility contract for the Go SDK. Anything that was made public could not be changed from Helm 2.0.0

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

I think what Jimmy is suggesting fits in with the first option of: 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

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

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

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. Attachments: Outlook-1504220459.png

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

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

+1

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

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

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

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