Date   

PSA: Helm v3 and the Stable repository

Matt Farina
 

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous distributed repositories this has given the impression or feel of a central repository. The central repository has become more than a handful to manage and scale so it isn't going to work for the next phase of Helm growth.

This is where the Helm Hub comes in. We want to encourage people to host their own charts and share them in a more discoverable place. That is the Helm Hub.

With that in mind, the stable repository has been removed from Helm v3. When you initialize Helm no repository is added by default.


Re: help to learn

Martin Hickey
 

Hi,
 
Welcome to Helm.
 
Documentation is a good place to start. The current release is Helm v2 and the documentation is at:  https://helm.sh/docs/.
 
The Helm community README provides a lot of good information for getting started in the community: https://github.com/helm/community 
 
If you have any questions, feel free to reach out in the #helm-users slack channel: https://kubernetes.slack.com/messages/C0NH30761

Regards,
Martin
 

----- Original message -----
From: veereshreddy.r@...
Sent by: cncf-helm@...
To: cncf-helm@...
Cc:
Subject: [EXTERNAL] [cncf-helm] help to learn
Date: Tue, Jul 30, 2019 9:37 AM
 
hello ,

need some resources to learn helm ,please help me.

thank you!
 


help to learn

veereshreddy.r@...
 

hello ,

need some resources to learn helm ,please help me.

thank you!


New repo for Helm acceptance tests

Josh Dolitsky
 

Hi all, please see this new repo started as the home for Helm acceptance testing:
https://github.com/helm/acceptance-testing

This is a test suite built using the Robot Framework, with Python libraries underneath. Uses tools such as kind to spin up Kubernetes clusters at different versions and test Helm functionality.

Looking for contributors if anybody wants to get involved! Here is a fun first issue: https://github.com/helm/acceptance-testing/issues/3

Thank you,

Josh


PSA: Timelines For Removing Kuberntes Deprecated APIs - extensions/v1beta1, apps/v1beta1, apps/v1beta2

Matt Farina
 

Kubernetes has an API deprecation policy. The extensions/v1beta1, apps/v1beta1, and apps/v1beta2 APIs are long past their deprecation window. They are now being deprecated.

In Kubernetes 1.16 (the next minor release) the following API objects will no longer be accepted by the API server:

  • DaemonSet, Deployment, StatefulSet, and ReplicaSet from the extensions/v1beta1, apps/v1beta1, or apps/v1beta2 API groups. Please migrate to apps/v1 which works all the way back to Kubernetes 1.9
  • PodSecurityPolicy from the extensions/v1beta1 API Group. Please migrate to policy/v1beta1 which has been available since Kubernetes 1.10
  • NetworkPolicy from extensions/v1beta1 API group. Please migrate to networking.k8s.io/v1 which has been available since Kubernetes 1.8.

In Kubernetes 1.18 Ingress from the extensions/v1beta1 API group will no longer be accepted. As of Kubernetes 1.14 it is available under the networking.k8s.io/v1beta1 API group. Migrating this API will be more difficult as public cloud providers are only just not beginning to support Kubernetes 1.14. It may be useful to detect either Kubernetes or the objects existence in the chart and generate the proper resource.

If there are any questions please feel free to ask.

- Matt Farina


Helm Interest at CloudNativeCon/KubeCon EU 2019

Matt Farina
 

The CNCF put out a transparency report for this past EU conference. One of the things that caught my attention was that of the CNCF projects only Kubernetes and Prometheus had more interest than Helm from attendees (see page 9 of the PDF full report).

If you like data and information on what happened there this report is a good place to get it.


Re: Happy Helming in China!

Will Zhou
 

That's really nice as that of docker image mirror landing in mainland China:)

On Tue, Jun 25, 2019 at 8:55 AM Paul Czarkowski <pczarkowski@...> wrote:
Great work! I'm familiar with how painful it can be to operate systems in China, this is a great step into making things more Accessible to the Chinese audience.

On Sun, Jun 23, 2019 at 11:07 AM Carlos Tadeu Panato Jr <ctadeu@...> wrote:
Pretty cool!

On Sat, Jun 22, 2019, 21:59 <resouer@...> wrote:
Hello Helm

As we discussed on Helm weekly meeting of June 6, 2019, we tried set up a mirror of Helm Hub in China and it has been published here: https://developer.aliyun.com/hub

It's 100% free and open source, replaced all unavailable URLs in the chart, verify the chart by a Kubernetes cluster (CI), and publish chart to AppHub portal.

We highly encouraged you read its README about its details here: https://github.com/cloudnativeapp/charts, and feel free to let us know your ideas by sending issue or PR.

```
helm repo add apphub https://apphub.aliyuncs.com
```
and

Happy Helming in China!


Re: Happy Helming in China!

Paul Czarkowski <pczarkowski@...>
 

Great work! I'm familiar with how painful it can be to operate systems in China, this is a great step into making things more Accessible to the Chinese audience.


On Sun, Jun 23, 2019 at 11:07 AM Carlos Tadeu Panato Jr <ctadeu@...> wrote:
Pretty cool!

On Sat, Jun 22, 2019, 21:59 <resouer@...> wrote:
Hello Helm

As we discussed on Helm weekly meeting of June 6, 2019, we tried set up a mirror of Helm Hub in China and it has been published here: https://developer.aliyun.com/hub

It's 100% free and open source, replaced all unavailable URLs in the chart, verify the chart by a Kubernetes cluster (CI), and publish chart to AppHub portal.

We highly encouraged you read its README about its details here: https://github.com/cloudnativeapp/charts, and feel free to let us know your ideas by sending issue or PR.

```
helm repo add apphub https://apphub.aliyuncs.com
```
and

Happy Helming in China!


Re: Happy Helming in China!

Carlos Tadeu Panato Jr
 

Pretty cool!


On Sat, Jun 22, 2019, 21:59 <resouer@...> wrote:
Hello Helm

As we discussed on Helm weekly meeting of June 6, 2019, we tried set up a mirror of Helm Hub in China and it has been published here: https://developer.aliyun.com/hub

It's 100% free and open source, replaced all unavailable URLs in the chart, verify the chart by a Kubernetes cluster (CI), and publish chart to AppHub portal.

We highly encouraged you read its README about its details here: https://github.com/cloudnativeapp/charts, and feel free to let us know your ideas by sending issue or PR.

```
helm repo add apphub https://apphub.aliyuncs.com
```
and

Happy Helming in China!


Happy Helming in China!

Lei Zhang
 

Hello Helm

As we discussed on Helm weekly meeting of June 6, 2019, we tried set up a mirror of Helm Hub in China and it has been published here: https://developer.aliyun.com/hub

It's 100% free and open source, replaced all unavailable URLs in the chart, verify the chart by a Kubernetes cluster (CI), and publish chart to AppHub portal.

We highly encouraged you read its README about its details here: https://github.com/cloudnativeapp/charts, and feel free to let us know your ideas by sending issue or PR.

```
helm repo add apphub https://apphub.aliyuncs.com
```
and

Happy Helming in China!


CRDs and Helm

Matt Farina
 

Consider this email an invitation to get involved.

Wouldn’t it be good if Helm was better with CRDs? Helm currently has the `crd-install` lifecycle hook. In charts we can use the Capabilities to detect if a CRD is already present (with improvements in that coming). But, people want more. How do we get there?

CRDs are hard for several reasons:
  • They are still in beta. Some changes are likely still coming. Helm has a strong focus on stability. Kubernetes has a beta deprecation policy for APIs and is now starting to exercise it for some objects that have GA versions.
  • CRDs are global and require high level access to install them. CRDs are being used for a wide variety of things including applications. Some who want to install these do not have access to install CRDs
  • How should CRD updates be handled? What if two people install a chart with the same CRD and those two installations are for applications in different namespaces and there is no knowledge between the two?

This is just to illustrate the complexity. There is more to it.

There have been some ideas and discussion on the topic including:


Both of these have issues that need to be designed around.

Do you have ideas on making this work or solving some of the design problems? If so, we welcome the insight and help.

-- 
Matt Farina
mattfarina.com




Get Helm from get.helm.sh

Matt Farina
 

&tldr; The Helm client can now be downloaded from get.helm.sh. This is the new primary source we will ship the client from and the only location to get Helm v3. Helm v3 alpha1 builds are there now. All of the Helm v2 versions are available there. If you use the get script it will now pull from this location. If you use 
CI you can replace kubernetes-helm.storage.googleapis.com with get.helm.sh. We plan on continuing to support the existing download location until we no longer support Helm v2. But, we encourage you to switch because of some of the new features listed below.

Why The Change

The Helm Client has long been available to download from https://kubernetes-helm.storage.googleapis.com. This bucket in Google Cloud has been used by Helm since before Kubernetes was part of the CNCF. Google, rather than the CNCF, has long been gracious in providing for this location. Since Helm started using it, Helm (as part of Kubernetes) moved into the CNCF and then moved out from under the Kubernetes umbrella to become a sister project to Kubernetes in the CNCF.

The CNCF is in the process of taking over the infrastructure for Kuberentes. It was time for Helm to move from a Google funded distribution location to one funded elsewhere. Google Cloud buckets cannot be transferred between projects. This means we need to move to a new URL location as part of the move.

What The New Location Provides

Moving locations provides us the opportunity to support some new features including:

  1. A URL we control so we do not need to change it again in the future. If the storage provider needs to change later we can have the URL point at the new location without this level of disruption going forward.
  2. Downloads in China. China is a large market for the CNCF and Helm. The Google Cloud Bucket is not accessible in China. The new location is and we are seeing just how popular Helm downloads are in China.
  3. Delivery via CDN. get.helm.sh is fronted by a CDN. This should provider faster downloads to those distributed around the world.

Tiller Has Not Moved

This change is only for the client download. Tiller has not moved to a new location. For Helm v3 there is no Tiller component.

If you have any questions about this change please let us know.


Special thanks to Matt Fisher who did the bulk of the work to setup the new location, update the automation, and make this possible.

-- 
Matt Farina
mattfarina.com




CFP deadline for Helm Summit is today!

Matt Fisher <matt.fisher@...>
 

Today is the last day to submit your CFPs for Helm Summit! Helm Summit will be in Amsterdam on September 11-12, 2019.

If you need help with your idea, I'm always happy to provide a helping hand! Feel free to shoot me an email with your ideas and I'll try to help where I can.

CFP submission page here: https://events.linuxfoundation.org/events/helm-summit-2019/program/call-for-proposals/


Happy Friday!

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


Helm 3.0.0-alpha.1 and 2.14.0 have been released!

Matt Fisher <matt.fisher@...>
 

Hey everyone! Helm 3.0.0-alpha.1 has been released. You can read all about what's changed by reading the release notes here.

This is only the first alpha release, and we'll still continue to add more features to Helm 3 as we iterate on future alpha releases. This is incredibly early software and bugs are to be expected (as with all alpha releases), so please do not run this in production.

If you want to get involved with testing the alpha (or to start contributing), we'd love to hear from you! Please feel free to reach out on Slack or feel free to reach out to me directly. 🙂

Finally, I wanted to give out a HUGE thank you to everyone who participated and contributed to the release. This was a massive undertaking, and we're just getting started together. We could not have done it without your continued help and support, and I cannot wait for what's ahead. Thank you.

As an additional note, Helm 2.14.0 was released today as well, and you can read the release notes for 2.14.0 here. Hooray for synchronized release schedules!


Cheers!

Matt


Re: Centralized Tiller deployments

Matt Fisher <matt.fisher@...>
 

This was originally the design goal of rudders and the rudder-federation project. The last activity that initiative had seen was over 2 years ago, and the core maintainer who was developing that project recently became an emeritus member.

As Kevin mentioned, I'd look into Kubernetes Federation v2. There hasn't been much activity on federated tillers in a *long* time.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of via Lists.Cncf.Io <Kevin.Fox=pnnl.gov@...>
Sent: Friday, April 19, 2019 8:35 AM
To: saldazzo@...; cncf-helm@...
Cc: cncf-helm@...
Subject: Re: [cncf-helm] Centralized Tiller deployments
 
It can not. You can get some of that functionality via Kubefed:
https://github.com/kubernetes-sigs/federation-v2

A central tiller can load kubefed objects that go out to other clusters.

Thanks,
Kevin

From: cncf-helm@... [cncf-helm@...] on behalf of saldazzo@... [saldazzo@...]
Sent: Thursday, April 18, 2019 6:07 PM
To: cncf-helm@...
Subject: [cncf-helm] Centralized Tiller deployments

Hi,

I'm setting up a number of Kubernetes clusters and want to use Helm/Tiller to deploy charts. Let's call these clusters central, dev, stg, and prod.I'm wondering if it's possible to install Tiller into the central cluster and give it access to deploy into other clusters like dev, stg, and prod. That way I'm not duplicating charts across clusters. I imagine there would be some service account magic that would need to happen across clusters, but I'm not sure that tiller can access other clusters or if it's tied to single clusters.

Here's a diagram of what I'm trying to accomplish.


Re: Centralized Tiller deployments

Fox, Kevin M <Kevin.Fox@...>
 

It can not. You can get some of that functionality via Kubefed:
https://github.com/kubernetes-sigs/federation-v2

A central tiller can load kubefed objects that go out to other clusters.

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of saldazzo@... [saldazzo@...]
Sent: Thursday, April 18, 2019 6:07 PM
To: cncf-helm@...
Subject: [cncf-helm] Centralized Tiller deployments

Hi,

I'm setting up a number of Kubernetes clusters and want to use Helm/Tiller to deploy charts. Let's call these clusters central, dev, stg, and prod.I'm wondering if it's possible to install Tiller into the central cluster and give it access to deploy into other clusters like dev, stg, and prod. That way I'm not duplicating charts across clusters. I imagine there would be some service account magic that would need to happen across clusters, but I'm not sure that tiller can access other clusters or if it's tied to single clusters.

Here's a diagram of what I'm trying to accomplish.


Centralized Tiller deployments

sal
 

Hi,

I'm setting up a number of Kubernetes clusters and want to use Helm/Tiller to deploy charts. Let's call these clusters central, dev, stg, and prod.I'm wondering if it's possible to install Tiller into the central cluster and give it access to deploy into other clusters like dev, stg, and prod. That way I'm not duplicating charts across clusters. I imagine there would be some service account magic that would need to happen across clusters, but I'm not sure that tiller can access other clusters or if it's tied to single clusters.

Here's a diagram of what I'm trying to accomplish.


Re: Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@v1.4.0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

Matt Fisher <matt.fisher@...>
 

Sorry, first sentence meant to say `go mod` not dep.

 

From: Matthew Fisher <Matt.Fisher@...>
Date: Tuesday, April 16, 2019 at 7:57 AM
To: "soolaugust@..." <soolaugust@...>, "cncf-helm@..." <cncf-helm@...>
Subject: Re: [cncf-helm] Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

 

As far as we know, dep has a *lot* of issues when it comes to dependency resolution. Helm 2 uses glide, but Helm 3 uses dep. Both are being planned for deprecation (with the former being officially deprecated), but they’re still stable workhorses and will work in a production scenario. I’d suggest trying an alternative package manager entirely. `go mod` is still very early and is why we haven’t migrated over because of issues like this.

 

Matt

 

From: <cncf-helm@...> on behalf of "soolaugust via Lists.Cncf.Io" <soolaugust=gmail.com@...>
Reply-To: "soolaugust@..." <soolaugust@...>
Date: Monday, April 1, 2019 at 5:52 PM
To: "cncf-helm@..." <cncf-helm@...>
Cc: "cncf-helm@..." <cncf-helm@...>
Subject: [cncf-helm] Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

 

Hi all,

I want to build a Golang project with helm, but when I try to get helm package, I got following error:

go: github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"

I google it and try to use "replace github.com/Sirupsen/logrus v1.4.0 => github.com/sirupsen/logrus v1.4.0" making package redirect to "sirupsen/logrus@....0". This problem solved but others following behind. I got a lot different errors when get other dependencies. 

So I want to know if helm package still be maintained. Thanks in advance :)


Re: Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@v1.4.0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

Matt Fisher <matt.fisher@...>
 

As far as we know, dep has a *lot* of issues when it comes to dependency resolution. Helm 2 uses glide, but Helm 3 uses dep. Both are being planned for deprecation (with the former being officially deprecated), but they’re still stable workhorses and will work in a production scenario. I’d suggest trying an alternative package manager entirely. `go mod` is still very early and is why we haven’t migrated over because of issues like this.

 

Matt

 

From: <cncf-helm@...> on behalf of "soolaugust via Lists.Cncf.Io" <soolaugust=gmail.com@...>
Reply-To: "soolaugust@..." <soolaugust@...>
Date: Monday, April 1, 2019 at 5:52 PM
To: "cncf-helm@..." <cncf-helm@...>
Cc: "cncf-helm@..." <cncf-helm@...>
Subject: [cncf-helm] Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

 

Hi all,

I want to build a Golang project with helm, but when I try to get helm package, I got following error:

go: github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"

I google it and try to use "replace github.com/Sirupsen/logrus v1.4.0 => github.com/sirupsen/logrus v1.4.0" making package redirect to "sirupsen/logrus@....0". This problem solved but others following behind. I got a lot different errors when get other dependencies. 

So I want to know if helm package still be maintained. Thanks in advance :)


Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@v1.4.0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

soolaugust@...
 

Hi all,

I want to build a Golang project with helm, but when I try to get helm package, I got following error:
go: github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"
I google it and try to use "replace github.com/Sirupsen/logrus v1.4.0 => github.com/sirupsen/logrus v1.4.0" making package redirect to "sirupsen/logrus@....0". This problem solved but others following behind. I got a lot different errors when get other dependencies. 

So I want to know if helm package still be maintained. Thanks in advance :)

261 - 280 of 454