Thanks for letting us know about this! We are currently working on the finishing touches for the first beta, so I will take a better look at this next week.

Hi folks, I've been looking into peribolos, a tool used at the Kubernetes org, for automating our Helm GitHub organization & team membership. Basically this means the Helm organization config will be

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,

Yes numerous services. I have two objectives. One is to make software in loop testing of drones more reproducible and the other is to create a scalable system to study network interaction.

Hi Joni. Is this flight simulation system one application with numerous microsevices? If so, it may make sense to do it as a single chart. That's what I would do. Are you going to share this chart

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