Date   

Re: PSA: Helm v3 and the Stable repository

Paul Czarkowski <pczarkowski@...>
 

While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool.  For better or worse being able to run `helm install stable/wordpress` <insert preferred demo project here> is great for a person to get that initial "hey look I did something useful!" feeling.  I have the feeling that any quickstart guide will simple have `helm repo add stable ...` as a second command anyway.

I'm not saying we shouldn't remove it, but I feel like there might be some reduction in the experience for new users that we should make sure we've considered.

On Tue, Jul 30, 2019 at 1:25 PM Matt Farina <matt@...> wrote:
Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

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

Paul Czarkowski <pczarkowski@...>
 

Welcome to the Helm Community!

I recently took my friend JJ through getting started with Helm and he streamed it to twitch and then uploaded to youtube.  If you want to watch us go from zero to hosting our own helm repo in about 3 hours ( can watch at 1.5x and skip bits ) it would probably teach you a lot.


On Tue, Jul 30, 2019 at 3:37 AM <veereshreddy.r@...> wrote:
hello ,

need some resources to learn helm ,please help me.

thank you!


Re: PSA: Helm v3 and the Stable repository

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

On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

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: PSA: Helm v3 and the Stable repository

Matt Farina
 

Great question. Two things come to mind.

1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if someone wants to help.

2) I would like to tie the Helm Hub into `helm search` so that anything in there can be discoverable. We still need to deal with alternative search endpoints and just data held locally. I do not want searches to internal systems leaked.  This has not happened either. If someone wants to help with this it would be appreciated.

Does that help?

On Tue, Jul 30, 2019, at 2:18 PM, Fox, Kevin M wrote:
On init, does it at least point folks to the hub.helm.sh site so they can find things easier?

Thanks,
Kevin


From: cncf-helm@... [cncf-helm@...] on behalf of Matt Farina [matt@...]
Sent: Tuesday, July 30, 2019 11:07 AM
To: cncf-helm@...
Subject: [cncf-helm] PSA: Helm v3 and the Stable repository

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.


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.

261 - 280 of 458