Date   

Add my Udemy course to Related Projects and Documentation section

usample12@...
 

Can I add my Udemy course (https://www.udemy.com/course/helm-the-kubernetes-package-manager-course) to Related Projects and Documentation section (https://helm.sh/docs/related/). Can anyone guide me through the steps ?


Install apps using helm3 on multiple clusters with --kube-context

siddhesh.divekar@...
 

Hi,
In helm2 "helm init" would install tiller using current cluster context.
Can I do this in parallel on multiple clusters using "--kube-context".

We are just starting to use helm so leaning towards using helm3.

With helm3 since tiller is gone,
can I use --kube-context option to install packages on multiple clusters in parallel ?

Will there be any conflicts with helm3 ?

Thanks,
Siddhesh


Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Matt Farina
 

+ Steve

On Wed, Aug 21, 2019, at 11:42 PM, Matt Farina wrote:
Steve, you ask a great question here. Specifically...

Now that we have artifacts accepted as an OCI project, what is the thought process to pull this out of experimentation?

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:
  1. The UX within the Helm needs to be completed. That includes things like search, signing, and other areas.
  2. Helm needs to implement the spec appropriate for artifacts. Looking at the artifacts repo, which was created on August 11th, I don't yet see those details in a release form. We'll need to understand those details (which I imagine Josh is well up to speed on) and where they sit within a release cycle. We don't want to release a stable feature in Helm holding to SemVer on it with something in development that may change at any time.
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:
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:
  • Unresolved UX issues. For example, you currently cannot "helm install" a registry-based chart without first exporting it to local directory
  • OCI compliance - the artifacts repo has been created, but it does not yet provide concrete, agreed-upon guidelines for alternate artifact support
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:

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.

  • ACR already supports Helm
  • ecr has said they will, when it gets adopted.
  • Harbor is also looking to support artifacts, including helm 3.
  • Quay either already supports, or would support – (jimmy ? )

 

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

Now that we have artifacts accepted as an OCI project, what is the thought process to pull this out of experimentation?

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:
  1. The UX within the Helm needs to be completed. That includes things like search, signing, and other areas.
  2. Helm needs to implement the spec appropriate for artifacts. Looking at the artifacts repo, which was created on August 11th, I don't yet see those details in a release form. We'll need to understand those details (which I imagine Josh is well up to speed on) and where they sit within a release cycle. We don't want to release a stable feature in Helm holding to SemVer on it with something in development that may change at any time.
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:
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:
  • Unresolved UX issues. For example, you currently cannot "helm install" a registry-based chart without first exporting it to local directory
  • OCI compliance - the artifacts repo has been created, but it does not yet provide concrete, agreed-upon guidelines for alternate artifact support
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:

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.

  • ACR already supports Helm
  • ecr has said they will, when it gets adopted.
  • Harbor is also looking to support artifacts, including helm 3.
  • Quay either already supports, or would support – (jimmy ? )

 

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

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.





On Aug 21, 2019, at 4:56 AM, Taylor Thomas <taylor@...> wrote:

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:
Of course, this weekend’s developer calls should be ok. Just remember to give me some minutes on the meeting


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:
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: 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:
  • Unresolved UX issues. For example, you currently cannot "helm install" a registry-based chart without first exporting it to local directory
  • OCI compliance - the artifacts repo has been created, but it does not yet provide concrete, agreed-upon guidelines for alternate artifact support
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:

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.

  • ACR already supports Helm
  • ecr has said they will, when it gets adopted.
  • Harbor is also looking to support artifacts, including helm 3.
  • Quay either already supports, or would support – (jimmy ? )

 

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?

 

 


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.

  • ACR already supports Helm
  • ecr has said they will, when it gets adopted.
  • Harbor is also looking to support artifacts, including helm 3.
  • Quay either already supports, or would support – (jimmy ? )

 

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:
Of course, this weekend’s developer calls should be ok. Just remember to give me some minutes on the meeting


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

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:
Of course, this weekend’s developer calls should be ok. Just remember to give me some minutes on the meeting


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

Hang Yan
 

Of course, this weekend’s developer calls should be ok. Just remember to give me some minutes on the meeting


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

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

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


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


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.

1504220459230_microsoft.png

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?"

1504220459230_microsoft.png

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

1) To document the feature as experimental in the CLI and in the documentation. Breaking changes may (likely?) happen to support the final implementation. It would not fall under Helms use of SemVer until it is no longer an experiment. We would likely not expose it via the usage information until it was ready.

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 not following the SemVer guarantee so as not to confuse people who have used it. This way everyone is clear that could break and isn't following SemVer.

Do we hit it behind a flag of something like `--experimental`?

On Tue, Aug 6, 2019, at 11:54 AM, Matt Farina wrote:
FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...

----- Original message -----
To: Matt Farina <matt@...>
Subject: Private: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Date: Tuesday, August 06, 2019 11:49 AM

Hey there,

I'd like to propose a third option which is to continue the existing work, but hide it from the CLI usage by default. This will allow continued development, but without user confusion. I'd argue that even if you tell people that the functionality is experimental, it'll confuse people unless they have to explicitly opt in somehow (e.g. export an environment variable).

While pulling out into a plug-in is a noble goal, App Registry was stifled a lot by the limitations of the plug-in model, which only compounded the difficulty of getting feature functionality finished. I think getting core functionality implemented first should be the priority and then a later version of Helm could focus development on pulling out as many features as possible into plug-ins.


221 - 240 of 457