|
Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Matt Farina
Steve, you ask a great question here. Specifically...
At KubeCon/CloudNativeCon EU this year we learned that there is good demand for Helm v3 sooner rather than later. Specifically, a Helm without Tiller. Having to install Tiller has proven to be problematic for several reasons in many environments. Especially those that lock down access for security. With that in mind we pulled back on all the features we wanted for v3.0.0 in order to get this out the door more quickly. We are entering the home stretch in our effort to get that out the door. That meant some of the features we wanted to have in the 3.0.0 are going to have to wait for a feature release (minor version increment in SemVer terms). Charts in registries was one of those features. In my mind, for charts in registries to become a reality we need a couple things:
I'm excited to have Helm charts in repositories. We just need to make sure we dot the i's and cross the t's prior to telling everyone it's stable. I look forward to that happening in a feature release. In addition to these two things I would like to see the Helm Hub be able display charts in registries. I wouldn't call this a blocker for the Helm CLI, though. All of these are areas we are open to contributions if anyone is interested. Steve, how will the registries support something that doens't have documented guidance that's released with a version (more than dev)? You noted ACR does while ECR and Harbor are looking at it. Do you know the timetable for the OCI artifacts project to get to releases with directions for projects? Thanks, Matt Farina On Wed, Aug 21, 2019, at 7:24 PM, Josh Dolitsky wrote:
|
|
|
|
Re: A Helm3 Controller
Hang Yan
We have encounter one design issue that is hard to decide: rollback
In helm2, it’s easy to do, because all the states are stored in Release. But in Helm3’s CRD, it’s both stored in HelmRequest and Release. It will cause inconsistent
if we still rollback the release object, because we also need to find a way to update the HelmRequest. It’s especially hard after we add support for multi cluster, which the release object and HelmRequest may not exist in the same cluster.
If we do this the kubernetes way, like Deployment, it’s history is in the
ReplicaSet object, then we will need to have a CRD like HelmRquestHistory, thus the Release Version object will be totally useless, one release would be sufficient for on HelmRequestHistory. I think the Helm3 Design proposal should consider this again.
|
|
|
|
Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Josh Dolitsky
Just so everyone has reference, Steve is referring to the fact that the "chart" and "registry" subcommands in Helm 3 are hidden behind an experimental env var. For more info, please see this doc: https://v3.helm.sh/docs/topics/registries/ IMO the registry stuff has been marked experimental in Helm 3 at this point for a few reasons:
Helm chart support across all registry providers would be nice of course, but this isn't what's primarily keeping these things from getting out of experimental mode. For now, we can start instructing users to set HELM_EXPERIMENTAL_OCI=1 in their environment if interested in using registries at this early stage. Josh
On Wed, Aug 21, 2019 at 4:09 PM Steve Lasker <StevenLasker@...> wrote:
|
|
|
|
How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Steve Lasker <StevenLasker@...>
Now that we have artifacts accepted as an OCI project, what is the thought process to pull this out of experimentation? This isn’t as much a chicken/egg scenario as cart/horse. Registries will prioritize enabling artifacts as there are interesting artifacts to store.
We know the current limitations of storing lots of helm charts with index.yaml. Artifact support solves the automation of chart builds not toppling over index.yaml.
Is the question whether someone using helm would have a registry?
|
|
|
|
Re: A Helm3 Controller
Paul Czarkowski <pczarkowski@...>
Just wanted to chime in! this is great, I just did a quick run through of it with some examples and it worked great. I look forward to getting some time to really dig into it.
On Tue, Aug 20, 2019 at 11:19 AM Hang Yan <hangyan@...> wrote:
|
|
|
|
Re: A Helm3 Controller
Taylor Thomas
Sure thing! It has been added to the agenda for this week: https://docs.google.com/document/d/1d-6xJEx0C78csIYSPKJzRPeWaHG_8W1Hjl72OJggwdc -Taylor
On Tue, Aug 20, 2019 at 10:19 AM Hang Yan <hangyan@...> wrote:
|
|
|
|
Re: A Helm3 Controller
Hang Yan
Of course, this weekend’s developer calls should be ok. Just remember to give me some minutes on the meeting
Get Outlook for iOS
From: Taylor Thomas <taylor@...>
Sent: Wednesday, August 21, 2019 12:16:19 AM To: Matt Butcher <matt.butcher@...> Cc: cncf-helm@... <cncf-helm@...>; Hang Yan <hangyan@...> Subject: Re: [cncf-helm] A Helm3 Controller Ok, I finally had a chance to take a look at this and it looks really good, especially for tracking along with the Helm 3 alpha releases. Is this something you'd like to demo during one of the Helm developer calls? I think it would be good for
others in the community to see it in action
On Thu, Aug 15, 2019 at 11:11 AM Matt Butcher via
Lists.Cncf.Io <matt.butcher=microsoft.com@...> wrote:
|
|
|
|
Re: A Helm3 Controller
Taylor Thomas
Ok, I finally had a chance to take a look at this and it looks really good, especially for tracking along with the Helm 3 alpha releases. Is this something you'd like to demo during one of the Helm developer calls? I think it would be good for others in the community to see it in action
On Thu, Aug 15, 2019 at 11:11 AM Matt Butcher via Lists.Cncf.Io <matt.butcher=microsoft.com@...> wrote:
|
|
|
|
Re: A Helm3 Controller
Matt Butcher <matt.butcher@...>
I read through the source yesterday, and this is looking good! Several people from WeaveWorks were interested in pursuing this idea as well. Hopefully some are on this list and may be able to take a look.
From: cncf-helm@... <cncf-helm@...> on behalf of hangyan via Lists.Cncf.Io <hangyan=alauda.io@...>
Sent: Tuesday, August 13, 2019 12:32 AM To: cncf-helm@... <cncf-helm@...> Cc: cncf-helm@... <cncf-helm@...> Subject: [cncf-helm] A Helm3 Controller 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, ChartRepo..). At first, we were struggled to deal with the ‘resource conflicts’ problem in helm2, and after some research we thought create a controller based
on the helm3 proposal is a good idea, and we did it. Any suggestions are welcome.
|
|
|
|
Re: A Helm3 Controller
Taylor Thomas
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.
|
|
|
|
[DISCUSS] Automate the management of GitHub org/team membership
Roy Lenferink <lenferinkroy@...>
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 stored in a
simple yaml file. Inviting new contributors can go through GitHub issues
or pull requests. A web hook will then trigger peribolos which invites the user (e.g. invited by helm-bot). Next to inviting new contributors, peribolos is able to manage
team membership as well. Because changes are going through pull requests
discussions are public as well and will be kept for historical
purposes, e.g.: https://github.com/kubernetes/org/
For a more advanced description, I've created the following helm/community GitHub issue: https://github.com/helm/community/issues/96 I'll volunteer to help out with getting this setup but it requires me to be added as a Helm org admin. When we decide we want to this and a working setup is available, our Helm community docs can be updated as well to describe our "new member" workflow. I'll leave this post open for a couple of days, if there are no objections after a few days I'll coordinate with the Helm maintainers to get this up and running. Cheers, Roy
|
|
|
|
A Helm3 Controller
Hang Yan <hangyan@...>
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, ChartRepo..).
At first, we were struggled to deal with the ‘resource conflicts’ problem in helm2, and after some research we thought create a controller based on the helm3 proposal is a good idea, and we did it. Any suggestions are welcome.
|
|
|
|
Re: Complex charts
j.g.pelham@...
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. Hopefully integrate it with ROS at some
point as well. Some nodes quite compute intensive but the network has the most load.
It would probably be an MIT license or one of the open ones. Do you know of anything anyone has done which has any similarity which I could look at?
Joni
From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina <matt@...>
Sent: Tuesday, August 13, 2019 5:20:09 PM To: cncf-helm@... <cncf-helm@...> Subject: Re: [cncf-helm] Complex charts 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 publicly or keep it private? If you are going to keep it private it may make sense to use a single chart. If it's public and uses some common components (e.g., mariadb or postgresql) it may make sense to depend on another
chart for one of those.
One flat chart with some templating is fine to do.
Hope that helps
- Matt Farina
On Tue, Aug 13, 2019, at 2:50 AM, j.g.pelham@... wrote:
|
|
|
|
Re: Complex charts
Matt Farina
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 publicly or keep it private? If you are going to keep it private it may make sense to use a single chart. If it's public and uses some common components (e.g., mariadb or postgresql) it may make sense to depend on another chart for one of those. One flat chart with some templating is fine to do. Hope that helps - Matt Farina
On Tue, Aug 13, 2019, at 2:50 AM, j.g.pelham@... wrote:
|
|
|
|
Complex charts
j.g.pelham@...
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 like sockets. Maybe also some WebRTC further down the line. Maybe one flat chart with some templating to automate the notation required for what is linking to what? Has anyone tried this sort of thing before?
Kind regards Joni
|
|
|
|
A Helm3 Controller
Hang Yan
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, ChartRepo..). At first, we were struggled to deal with the ‘resource conflicts’ problem in helm2, and after some research we thought create a controller based on the helm3 proposal is a good idea, and we did it. Any suggestions are welcome.
|
|
|
|
Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Matt Fisher <matt.fisher@...>
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
From: cncf-helm@... <cncf-helm@...> on behalf of Matt Fisher via Lists.Cncf.Io <matt.fisher=microsoft.com@...>
Sent: Tuesday, August 6, 2019 11:53 AM To: Matt Farina <matt@...>; jimmyzelinskie@... <jimmyzelinskie@...> 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 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 registries.
The question I'm wondering is "If we're marking certain features of the client as experimental, should the SDK receive the same treatment? If so, how?"
Matthew Fisher Caffeinated Software Engineer
Microsoft Canada From: cncf-helm@... <cncf-helm@...> on behalf of via Lists.Cncf.Io <jimmyzelinskie=gmail.com@...>
Sent: Tuesday, August 6, 2019 10:04 AM To: Matt Farina <matt@...> 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
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 or not.
The Go compiler has been using environment variables for feature gating (e.g. GOMODULES111=on). Having to append `--experimental` to commands seems monotonous for those testing the functionality, although that might be desirable so that if anyone sees
the bash history (or is shown the command) it's extremely clear that the work isn't stable.
On Tue, Aug 6, 2019 at 12:59 PM Matt Farina <matt@...> wrote:
|
|
|
|
Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Matt Fisher <matt.fisher@...>
> 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 registries.
The question I'm wondering is "If we're marking certain features of the client as experimental, should the SDK receive the same treatment? If so, how?"
Matthew Fisher Caffeinated Software Engineer
Microsoft Canada
From: cncf-helm@... <cncf-helm@...> on behalf of via Lists.Cncf.Io <jimmyzelinskie=gmail.com@...>
Sent: Tuesday, August 6, 2019 10:04 AM To: Matt Farina <matt@...> 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
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 or not.
The Go compiler has been using environment variables for feature gating (e.g. GOMODULES111=on). Having to append `--experimental` to commands seems monotonous for those testing the functionality, although that might be desirable so that if anyone sees
the bash history (or is shown the command) it's extremely clear that the work isn't stable.
On Tue, Aug 6, 2019 at 12:59 PM Matt Farina <matt@...> wrote:
|
|
|
|
Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Jimmy Zelinskie <jimmyzelinskie@...>
>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 or not. The Go compiler has been using environment variables for feature gating (e.g. GOMODULES111=on). Having to append `--experimental` to commands seems monotonous for those testing the functionality, although that might be desirable so that if anyone sees the bash history (or is shown the command) it's extremely clear that the work isn't stable.
On Tue, Aug 6, 2019 at 12:59 PM Matt Farina <matt@...> wrote:
|
|
|
|
Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Josh Dolitsky
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 “helm init”? Thanks, Josh
On Tue, Aug 6, 2019 at 12:20 PM Matt Fisher via Lists.Cncf.Io <matt.fisher=microsoft.com@...> wrote:
|
|
|
