Date   

Re: Last v2 feature release

Matt Fisher
 

Good question. At this time, we do not have a cut date for 2.15. We may have to come up with a planned merge window for this release so contributors are aware of the deadline.

However, I imagine the cut window would be fairly short - likely within the next two weeks. Users have reported issues using Helm with Kubernetes 1.16 and there's a PR open to fix that. Once that's merged, we will likely be pressured to release 2.15 for that fix.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of Ihor Dvoretskyi via Lists.Cncf.Io <ihor=cncf.io@...>
Sent: Thursday, September 26, 2019 10:48 AM
To: Taylor Thomas <taylor@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] Last v2 feature release
 
What is the estimated cut date for this?

On Thu, Sep 26, 2019, 8:18 PM Taylor Thomas <taylor@...> wrote:
Hello all Helmettes! 

We have decided that Helm 2.15 will be the last feature release for Helm 2. This means that once it is cut, we will be moving the current master branch to be "release-2" and "dev-v3" will become the new master. Any currently open PRs with features will need to be targeted for v3 after that point.

PLEASE NOTE: This is the last _feature_ release. We will still be releasing bug and security fixes as needed.

Thank you for all of the feedback and for helping us maintain a great community!

-Taylor


Re: Last v2 feature release

Ihor Dvoretskyi
 

What is the estimated cut date for this?


On Thu, Sep 26, 2019, 8:18 PM Taylor Thomas <taylor@...> wrote:
Hello all Helmettes! 

We have decided that Helm 2.15 will be the last feature release for Helm 2. This means that once it is cut, we will be moving the current master branch to be "release-2" and "dev-v3" will become the new master. Any currently open PRs with features will need to be targeted for v3 after that point.

PLEASE NOTE: This is the last _feature_ release. We will still be releasing bug and security fixes as needed.

Thank you for all of the feedback and for helping us maintain a great community!

-Taylor


Last v2 feature release

Taylor Thomas
 

Hello all Helmettes! 

We have decided that Helm 2.15 will be the last feature release for Helm 2. This means that once it is cut, we will be moving the current master branch to be "release-2" and "dev-v3" will become the new master. Any currently open PRs with features will need to be targeted for v3 after that point.

PLEASE NOTE: This is the last _feature_ release. We will still be releasing bug and security fixes as needed.

Thank you for all of the feedback and for helping us maintain a great community!

-Taylor


Detecting Helm v2 and v3 in scripts

Matt Farina
 

If you are going to work with both Helm v2 and Helm v3 in your scripts this email is where we are looking for your input.

`helm version` in v2 and the forthcoming v3 work a little different. This includes the `-c` flag for client side version only (not available in v3 where it causes an error). You can get a rundown at https://github.com/helm/helm/issues/6322

Marc Khouzam noted that the acceptance-testing repo uses the following to detect the versions...

if helm version -c &> /dev/null; then
    // v2
else
    //v3
fi

This relies on the error response to detect the versions.

There is a proposed PR to add and ignore the `-c` flag to v3 in over to get the version when it's used. This means a script would need to parse the version to tell the difference between v2 and v3. But, it would provide the ability to read and detect the version with more accurate (e.g., detect minor versions)

The PR to add this flag is at https://github.com/helm/helm/pull/6368

If you are into scripting with helm which path would you prefer? Do you need to detect minor versions? If you have any feedback please feel free to leave it on the PR or in response to this message.


Re: Helm in-depth of Q/A for InfoQ

Matt Butcher
 

Sure! Please contact me directly and I will get things rolling.

Matt Butcher


From: cncf-helm@... <cncf-helm@...> on behalf of via Lists.Cncf.Io <raghavan.srinivas=gmail.com@...>
Sent: Tuesday, September 17, 2019 9:53 AM
To: Raghavan Srinivas <rags@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] Helm in-depth of Q/A for InfoQ
 
Matt/all:

Can someone help me please? Especially if you attended the summit. I can work with you even if you did not attend but consider yourself as a core Helm contributor.

Thanks!

Rags


On Sep 10, 2019, at 3:41 AM, Raghavan Srinivas <rags@...> wrote:

Hello Helm maintainers:

I reached out to Matt regarding an in-depth q and a for infoq. Since he does not have the bandwidth can anyone else step in here (his suggestion to reach out to list). It will take a max of 3 to 4 hours of your time spread over a few days.

Thanks!

Rags


From: Raghavan Srinivas <rags@...>
Sent: Monday, September 9, 2019 10:25:30 AM
To: Matt Fisher <Matt.Fisher@...>
Subject: Helm in-depth of Q/A for InfoQ
 

Matt:

 

Hope you’r having a great Helm Summit. Too bad, I am not in Amsterdam 

 

I part time write for InfoQ (as you probably know) and would like to do an indepth Helm Q/A similar to

 

https://www.infoq.com/profile/Rags-Srinivas/#allActivity

 

Would you have some bandwith (will take just about 2-3 hours of your time max to answer about 6-8 questions)? I am thinking of pushing this out this week or latest next and only after you green light the preview that I’ll send out.

 

Hopefully this works for you? LMK if I need to reach out to anyone else as well? If you’re not the right person (don’t know who else can it be for Helm ) then LMK as well.

 

Thanks!

 

Rags


Re: Helm in-depth of Q/A for InfoQ

Rags Srinivas <raghavan.srinivas@...>
 

Matt/all:

Can someone help me please? Especially if you attended the summit. I can work with you even if you did not attend but consider yourself as a core Helm contributor.

Thanks!

Rags


On Sep 10, 2019, at 3:41 AM, Raghavan Srinivas <rags@...> wrote:

Hello Helm maintainers:

I reached out to Matt regarding an in-depth q and a for infoq. Since he does not have the bandwidth can anyone else step in here (his suggestion to reach out to list). It will take a max of 3 to 4 hours of your time spread over a few days.

Thanks!

Rags


From: Raghavan Srinivas <rags@...>
Sent: Monday, September 9, 2019 10:25:30 AM
To: Matt Fisher <Matt.Fisher@...>
Subject: Helm in-depth of Q/A for InfoQ
 

Matt:

 

Hope you’r having a great Helm Summit. Too bad, I am not in Amsterdam 

 

I part time write for InfoQ (as you probably know) and would like to do an indepth Helm Q/A similar to

 

https://www.infoq.com/profile/Rags-Srinivas/#allActivity

 

Would you have some bandwith (will take just about 2-3 hours of your time max to answer about 6-8 questions)? I am thinking of pushing this out this week or latest next and only after you green light the preview that I’ll send out.

 

Hopefully this works for you? LMK if I need to reach out to anyone else as well? If you’re not the right person (don’t know who else can it be for Helm ) then LMK as well.

 

Thanks!

 

Rags


Re: Helm in-depth of Q/A for InfoQ

Raghavan "Rags" N. Srinivas <rags@...>
 

Hi all:

Now that the Helm summit is over, can someone please get to the helm for this in-depth Q/A? I don't want to lose momentum.

Thanks!

Rags

On Wed, Sep 11, 2019 at 9:44 AM Raghavan "Rags" N. Srinivas <rags@...> wrote:
Hi all:

Just a gentle ping. Realize everyone must be busy with the Helm summit which is why I am pushing to do this right after.

Matt, any chance you can prod someone please? :-)

Thanks!

Rags

On Tue, Sep 10, 2019 at 6:41 AM Raghavan Srinivas <rags@...> wrote:
Hello Helm maintainers:

I reached out to Matt regarding an in-depth q and a for infoq. Since he does not have the bandwidth can anyone else step in here (his suggestion to reach out to list). It will take a max of 3 to 4 hours of your time spread over a few days.

Thanks!

Rags


From: Raghavan Srinivas <rags@...>
Sent: Monday, September 9, 2019 10:25:30 AM
To: Matt Fisher <Matt.Fisher@...>
Subject: Helm in-depth of Q/A for InfoQ
 

Matt:

 

Hope you’r having a great Helm Summit. Too bad, I am not in Amsterdam 

 

I part time write for InfoQ (as you probably know) and would like to do an indepth Helm Q/A similar to

 

https://www.infoq.com/profile/Rags-Srinivas/#allActivity

 

Would you have some bandwith (will take just about 2-3 hours of your time max to answer about 6-8 questions)? I am thinking of pushing this out this week or latest next and only after you green light the preview that I’ll send out.

 

Hopefully this works for you? LMK if I need to reach out to anyone else as well? If you’re not the right person (don’t know who else can it be for Helm ) then LMK as well.

 

Thanks!

 

Rags


Re: Migrating Helm 2 to Helm 3

Rimas
 

And my blog post how to migrate to Helm v3 is published https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/ as well.


Migrating Helm 2 to Helm 3

Martin Hickey
 

Hi Folks,

The plugin for migrating Helm v2 configuration and releases in-place to Helm v3 is now available: https://github.com/helm/helm-2to3

Please check it out and give it a spin. Note: That the plugin is in beta like Helm 3 and should not be used in production yet.

Regards,
Martin


Re: Helm in-depth of Q/A for InfoQ

Raghavan "Rags" N. Srinivas <rags@...>
 

Hi all:

Just a gentle ping. Realize everyone must be busy with the Helm summit which is why I am pushing to do this right after.

Matt, any chance you can prod someone please? :-)

Thanks!

Rags

On Tue, Sep 10, 2019 at 6:41 AM Raghavan Srinivas <rags@...> wrote:
Hello Helm maintainers:

I reached out to Matt regarding an in-depth q and a for infoq. Since he does not have the bandwidth can anyone else step in here (his suggestion to reach out to list). It will take a max of 3 to 4 hours of your time spread over a few days.

Thanks!

Rags


From: Raghavan Srinivas <rags@...>
Sent: Monday, September 9, 2019 10:25:30 AM
To: Matt Fisher <Matt.Fisher@...>
Subject: Helm in-depth of Q/A for InfoQ
 

Matt:

 

Hope you’r having a great Helm Summit. Too bad, I am not in Amsterdam 

 

I part time write for InfoQ (as you probably know) and would like to do an indepth Helm Q/A similar to

 

https://www.infoq.com/profile/Rags-Srinivas/#allActivity

 

Would you have some bandwith (will take just about 2-3 hours of your time max to answer about 6-8 questions)? I am thinking of pushing this out this week or latest next and only after you green light the preview that I’ll send out.

 

Hopefully this works for you? LMK if I need to reach out to anyone else as well? If you’re not the right person (don’t know who else can it be for Helm ) then LMK as well.

 

Thanks!

 

Rags


Re: Helm in-depth of Q/A for InfoQ

Raghavan Srinivas <rags@...>
 

Hello Helm maintainers:

I reached out to Matt regarding an in-depth q and a for infoq. Since he does not have the bandwidth can anyone else step in here (his suggestion to reach out to list). It will take a max of 3 to 4 hours of your time spread over a few days.

Thanks!

Rags


From: Raghavan Srinivas <rags@...>
Sent: Monday, September 9, 2019 10:25:30 AM
To: Matt Fisher <Matt.Fisher@...>
Subject: Helm in-depth of Q/A for InfoQ
 

Matt:

 

Hope you’r having a great Helm Summit. Too bad, I am not in Amsterdam 

 

I part time write for InfoQ (as you probably know) and would like to do an indepth Helm Q/A similar to

 

https://www.infoq.com/profile/Rags-Srinivas/#allActivity

 

Would you have some bandwith (will take just about 2-3 hours of your time max to answer about 6-8 questions)? I am thinking of pushing this out this week or latest next and only after you green light the preview that I’ll send out.

 

Hopefully this works for you? LMK if I need to reach out to anyone else as well? If you’re not the right person (don’t know who else can it be for Helm ) then LMK as well.

 

Thanks!

 

Rags


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.

121 - 140 of 368