helm / charts

⚠️(OBSOLETE) Curated applications for Kubernetes

	This project is no longer supported.

Helm Charts

The canonical source for Helm charts is the Artifact Hub, an aggregator for distributed chart repos.

This GitHub project is the source for Helm stable and incubator Helm chart repositories. This is now an archive no longer under active development.

For more information about installing and using Helm, see the Helm Docs. For a quick introduction to Charts, see the Chart Guide.

⚠️ Deprecation and Archive Notice

Similar to the Helm 2 Support Plan, this GitHub project has begun transition to a 1 year "maintenance mode" (see Deprecation Timeline below). Given the deprecation plan, this project is intended for apiVersion: v1 Charts (installable by both Helm 2 and 3), and not for apiVersion: v2 charts (installable by Helm 3 only).

Deprecation Timeline

Nov 13, 2019	At Helm 3's public release, new charts are no longer accepted to stable or incubator. Patches to existing charts may continue to be submitted by the community, and (time permitting) reviewed by chart OWNERS for acceptance
Aug 13, 2020	At 9 months – when Helm v2 goes security fix only – the stable and incubator repos will be de-listed from the Helm Hub. Chart OWNERS are encouraged to accept security fixes only. ℹ️ Note: the original date has been extended 3 months to match Helm v2 support. See COVID-19: Extending Helm v2 Bug Fixes
Nov 13, 2020	At 1 year, support for this project will formally end, at which point the stable and incubator chart repos will be marked obsolete. At that time these chart repos will likely be garbage collected and no longer available. This git repository will remain as an archive.

This timeline gives the community (chart OWNERS, organizations, groups or individuals who want to host charts) 9 months to move charts to new Helm repos, and list these new repos on the Helm Hub before stable and incubator are de-listed.

Note that this project has been under active development for some time, so you might run into issues. If you do, please don't be shy about letting us know, or better yet, contribute a fix or feature (within the deprecation timeline of course). Also be aware the repo and chart OWNERS are volunteers so reviews are as time allows, and acceptance is up to the chart OWNERS - you may reach out but please be patient and courteous.

Where to Find Us

For general Helm Chart discussions join the Helm Charts (#charts) room in the Kubernetes Slack instance.

For issues and support for Helm and Charts see Support Channels.

How Do I Install These Charts?

Just helm install stable/<chart>. This is the default repository for Helm v2 which is located at https://charts.helm.sh/stable/ and was installed by default prior to Helm v3.

For more information on using Helm, refer to the Helm documentation.

How Do I Enable the Stable Repository for Helm 3?

To add the Helm Stable Charts for your local client, run helm repo add:

$ helm repo add stable https://charts.helm.sh/stable
"stable" has been added to your repositories

How Do I Enable the Incubator Repository?

To add the Incubator charts for your local client, run helm repo add:

$ helm repo add incubator https://charts.helm.sh/incubator
"incubator" has been added to your repositories

You can then run helm search incubator to see the charts.

Chart Format

Take a look at the alpine example chart for reference when you're writing your first few charts.

Before contributing a Chart, become familiar with the format. Note that the project is still under active development and the format may still evolve a bit.

Repository Structure

This GitHub repository contains the source for the packaged and versioned charts released using GitHub pages (the Chart Repository).

The Charts in the stable/ directory in the master branch of this repository match the latest packaged Chart in the Chart Repository, though there may be previous versions of a Chart available in that Chart Repository.

The purpose of this repository is to provide a place for maintaining and contributing official Charts, with CI processes in place for managing the releasing of Charts into the Chart Repository.

The Charts in this repository are organized into two folders:

• stable
• incubator

Stable Charts meet the criteria in the technical requirements.

Incubator Charts are those that do not meet these criteria. Having the incubator folder allows charts to be shared and improved on until they are ready to be moved into the stable folder. The charts in the incubator/ directory can be found on the gh-pages branch of the repository.

In order to get a Chart from incubator to stable, Chart maintainers should open a pull request that moves the chart folder.

Contributing to an Existing Chart

We'd love for you to contribute to an existing Chart that you find provides a useful application or service for Kubernetes. Please read our Contribution Guide for more information on how you can contribute Charts.

Note: We use the same workflow, License and Contributor License Agreement as the main Kubernetes repository.

Owning and Maintaining A Chart

Individual charts can be maintained by one or more users of GitHub. When someone maintains a chart they have the access to merge changes to that chart. To have merge access to a chart someone needs to:

1. Be listed on the chart, in the Chart.yaml file, as a maintainer. If you need sponsors and have contributed to the chart, please reach out to the existing maintainers, or if you are having trouble connecting with them, please reach out to one of the OWNERS of the charts repository.
2. Be invited (and accept your invite) as a read-only collaborator on this repo. This is required for @k8s-ci-robot PR comment interaction.
3. An OWNERS file needs to be added to a chart. That OWNERS file should list the maintainers' GitHub login names for both the reviewers and approvers sections. For an example see the Drupal chart. The OWNERS file should also be appended to the .helmignore file.

Once these three steps are done a chart approver can merge pull requests following the directions in the REVIEW_GUIDELINES.md file.

Trusted Collaborator

The pull-charts-e2e test run, that installs a chart to test it, is required before a pull request can be merged. These tests run automatically for members of the Helm Org and for chart repository collaborators. For regular contributors who are trusted, in a manner similar to Kubernetes community members, we have trusted collaborators. These individuals can have their tests run automatically as well as mark other pull requests as ok to test by adding a comment of /ok-to-test on pull requests.

There are two paths to becoming a trusted collaborator. One only needs follow one of them.

1. If you are a Kubernetes GitHub org member and have your Kubernetes org membership public you can become a trusted collaborator for Helm Charts
2. Get sponsorship from one of the Charts Maintainers listed in the OWNERS file at the root of this repository

The process to get added is:

• File an issue asking to be a trusted collaborator
• A Helm Chart Maintainer can then add the user as a read only collaborator to the repository

Review Process

For information related to the review procedure used by the Chart repository maintainers, see Merge approval and release process.

Stale Pull Requests and Issues

Pull Requests and Issues that have no activity for 30 days automatically become stale. After 30 days of being stale, without activity, they become rotten. Pull Requests and Issues can rot for 30 days and then they are automatically closed. This is the standard stale process handling for all repositories on the Kubernetes GitHub organization.

Supported Kubernetes Versions

This chart repository supports the latest and previous minor versions of Kubernetes. For example, if the latest minor release of Kubernetes is 1.8 then 1.7 and 1.8 are supported. Charts may still work on previous versions of Kubernertes even though they are outside the target supported window.

To provide that support the API versions of objects should be those that work for both the latest minor release and the previous one.

Happy Helming in China

If you are in China, there are some problems to use upstream Helm Charts directly (e.g. images hosted on gcr.io, quay.io, and Charts hosted on googleapis.com etc), you can use this mirror repo at https://github.com/cloudnativeapp/charts which automatically sync & replace unavailable image & repo URLs in every Chart.

charts's Issues

MariaDB: Add persistence by default support using PVCs

Should Mariadb have PV storage? If I have reading it correctly it is using a emptydir.

https://github.com/kubernetes/charts/blob/master/stable/mariadb/templates/deployment.yaml

Unable to get build log for PRs

@viglesiasce I had a failed build from a PR (#92), but when trying to access the logs it fails to load them from the bucket. Any ideas?

update index file format in incubator bucket

With the release of helm alpha.5, there is an updated index file structure. Currently, adding the incubator bucket emits a warning. We should regenerate the index file.

stable [master]$ helm repo add --debug incubator http://storage.googleapis.com/kubernetes-charts-incubator/
WARNING: Deprecated index file format. Try 'helm repo update'
"incubator" has been added to your repositories

Support for additional resources

I don't expect this to be supported anytime soon but I just wanted to bring this up. Kubernetes 1.2 was released about a week ago and with the release it brought a new resource.

Config Map

Now it is possible to use a config map to define your environment variables, an example I threw together is shown here

env:
  - name: TEAMCITY_SERVER_MEM_OPTS
    value: '-Xmx2500m'
  - name: TEAMCITY_SERVER_OPTS
    value: '-Dteamcity.git.fetch.separate.process=false'
  - name: TEAMCITY_DATA_PATH
    value: '/var/lib/teamcity'
  - name: CATALINA_OPTS
    valueFrom:
      configMapKeyRef:
      name: catalina-config
      key: proxy.properties

This isn't supported by the github.com/kubernetes/charts/common/replicatedservice:v2 template at the moment due to the assumption that every entry in env will have the keys 'name' and 'value'.

https://github.com/kubernetes/charts/blob/2ecf8f3cd3a12e36c2d9d4e1faf4ddd531c55838/common/replicatedservice/v2/replicatedservice.py#L192-L194.

for entry in tmp_env:
  if isinstance(entry, dict):
    env.append({'name': entry.get('name'), 'value': entry.get('value')})

Also, it looks like the following aren't supported at the moment as well, which Kubernetes has had prior to 1.2.

Limits and Requests

resources:
  requests:
    memory: "3Gi"
  limits:
    memory: "4Gi"

Liveness Probe

livenessProbe:
  httpGet:
    path: /mnt
    port: 8111
  initialDelaySeconds: 20
  timeoutSeconds: 2

I'd be happy to submit a pull request adding functionality to replicatedservice:v2, but I had a few questions first.

1. As Kubernetes comes out with support for additional resources, how quickly will these be supported? Is this template (replicatedservice:v2) trying to support all of the resources or only a popular subset?
2. Should this just be added to v2 or should a v3 be created?
3. Is someone already aware / working on this and should I just be patient and wait?

I know I can just fork and modify the template to suit my needs and then just use that, but then that wouldn't be any use to the community.

Populate "icon" Chart.yaml attribute

In the Helm Monocular project, we aim for indexing and exposing Helm Charts in a simple way via an user interface.

This interface relies on the Charts logos exposed via the "icon" attribute in the Chart.yaml files.

Currently, from the stable charts, only Jenkins includes this optional property.

It would be great to populate the existing icon attributes and "enforce" as a best practice its addition in new official charts.

Thoughts?

Need a golden chart to begin testing

In order to properly implement the CI process we will need at least 1 "golden" chart to use as a guinea pig.

Include the capability to set CPU and memory in MariaDB Chart

Should we include the capability to set CPU and memory? With the default settings, this would be a very small MySQL instance 😀

Create Infrastructure for Charts CI

The infrastructure will consist of:

• An autoscaled GKE cluster for running jobs, running the latest
• Jenkins instance that monitors PRs on this repo and runs them through a predefined pipeline of tests
• A GCS bucket for storing the the chart tarballs

[Stable/MariaDB] PVC being created even persistence.enabled = false

Steps to re-create:
helm install stable/mariadb --set persistence.enabled=false

You'll see that when you do a helm get [RELEASE] the value of persistence.enabled is set correctly to false but the PVC is still being created.

Version info:

$ helm version
Client: &version.Version{SemVer:"v2.0.0-beta.1", GitCommit:"58be8c9fce50f0657425443b83307ba91789b794", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.0.0-beta.1", GitCommit:"2eed3f0464ff88d1c8358388ce5472e835c35feb", GitTreeState:"clean"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.1+33cf7b9", GitCommit:"33cf7b9acbb2cb7c9c72a10d6636321fb180b159", GitTreeState:"not a git tree", BuildDate:"2016-10-13T15:18:15Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.0", GitCommit:"a16c0a7f71a6f93c7e0f222d961f4675cd97a46b", GitTreeState:"dirty", BuildDate:"1970-01-01T00:00:00Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"}

List of established examples / charts in order of priority to pull here

I thought I'd make a list here we can keep up to date of stuff to pull to this repository.

• MariaDB: by @sameersbn / http://bitnami.com, repo: #29
• Cassandra petsets: by @chrislovecnm, repo: ?
• Rethinkdb petset: by @paralin, repo: https://github.com/paralin/kubernetes-rethinkdb-cluster
• Crunchy Postgres: by @jmccormick2001, repo: #22

Feel free to add, or kill this issue if you think it's a bad idea to keep track of this here.

Index only contains latest charts

Helm Alpha.5 now omits older charts when doing a helm search so we should create the index with all the old charts now.

Image pull secrets for jenkins chart

The present jenkins chart does not provide an option for imagePullSecrets: for the master image. IMO it should be optional where it can be provided and chart should be able to use it for pulling the image.

Build process and Jenkinsfile

@viglesiasce I know you are not a java / groovy guru yet, so let me know what your plans are with Jenkinsfile and the testing process. Have some tweaks that I would recommend for the Jenkinfile if you like.

Compute Resources for existing charts

I know I am beating this dead horse just a bit, but we need to go through the existing charts and get http://kubernetes.io/docs/user-guide/compute-resources/ laid out. Probably should update any standards docs / guidelines that we have.

Teams for this repository don't have access to the repository

application-dm-templates-maintainers and application-dm-templates-collaborators have no assigned repositories.

• To correct this problem, visit each team under Teams in the Kubernetes organization.
• On the team page, select the Repositories tab. In the Repositories tab, add this repository to the team, and set the team's permissions appropriately.
  • For application-dm-templates-maintainers the permission should be Write.
  • For application-dm-templates-collaborators the permission should be Read.

Remove/disable Travis builds

Now that we've switched to the k8s jenkins infrastructure, we should disable the Travis builds, and remove the .travis.yml file from the repo.

Upgrading API versions and PetSet rename

So when do we upgrade API versions? Follow release schedule or do we make them vars?

Also PetSet name is being changed in 1.5. Need to plan that.

Also do we have upgrade path with helm?

Charts Repo Structure

We need a plan to deal with how charts are organized within this repo. If we continue down the path we are on (folder at the top level) we will quickly end up with an unwieldy top level structure.

Examples in the wild:

1. Mesosphere universe, folder per letter
   • repo
     • packages
       • A
       • B
     • meta
2. Docker Library, subfolder and file per app
   • library
     • A
     • B

[Stable/Drupal] Update MariaDB dependency

This chart should use the new requirements.yaml file and update the MariaDB dependency to be the MariaDB chart in stable/MariaDB.

Switch from Helm canary to beta.2?

@viglesiasce did we want to make the switch to using Helm beta.1 instead of the canary release?

Error while installing elasticsearch chart

Hey,

I'am unable to install the current state of the elasticsearch chart. When I execute the install command from the chart's Readme I get an JSON paring error:

[root@kube-master-1 ~]# helm install --name es-test-1 charts/incubator/elasticsearch
Error: release es-test-1 failed: [unable to decode "": [pos 301]: json: decNum: got first char '"', unable to decode "": [pos 301]: json: decNum: got first char '"', unable to decode "": [pos 288]: json: decNum: got first char '"']

The issue is a little bit hard to debug, as the input of this chart is all yaml and I don't know if and where the intermediate json gets stored.

Change format of charts

change format of merged charts from helm/charts to new unified format

depends on #6

Set up Charts release process

• Set up infrastructure (GKE cluster, GCS storage buckets)
• Set up CI (Jenkins) job for validating PRs
• Set up CI (Jenkins) job for releasing Charts to storage buckets

alpha vs. beta annotations for PVCs

I am using helm to install the chart stable/mariadb, the deploy was initialized successfully, but never finish, the pod status stuck at "Init:0/1".

Helm version: 2.0.0-alpha.5

root@c910f04x19k07:~/helm/bin# helm version
Client: &version.Version{SemVer:"v2.0.0-alpha.5", GitCommit:"a324146945c01a1e2dd7eaf23caf0e55fabfd3d2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.0.0-alpha.5", GitCommit:"1a7373e584f2b7732d902963f020fa72cc2e642f", GitTreeState:"clean"}
root@c910f04x19k07:~/helm/bin# 

Kubernetes version 1.3.6:

root@c910f04x19k07:~/helm/bin# kubectl version
Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.6", GitCommit:"ae4550cc9c89a593bcda6678df201db1b208133b", GitTreeState:"clean", BuildDate:"2016-08-26T18:13:23Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"3+", GitVersion:"cfc-0.1.0-dirty", GitCommit:"7577a50e5c71505e3458884f83590270bb693351", GitTreeState:"dirty", BuildDate:"2016-10-16T17:27:39Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
root@c910f04x19k07:~/helm/bin# 

Steps and output:

root@c910f04x19k07:~/helm/bin# helm search
NAME                    VERSION DESCRIPTION                                       
stable/drupal           0.3.2   One of the most versatile open source content m...
stable/jenkins          0.1.0   A Jenkins Helm chart for Kubernetes.              
stable/mariadb          0.5.1   Chart for MariaDB                                 
stable/mysql            0.1.0   Chart for MySQL                                   
stable/redmine          0.3.2   A flexible project management web application.    
stable/wordpress        0.3.0   Web publishing platform for building blogs and ...
root@c910f04x19k07:~/helm/bin# helm install stable/mariadb
Fetched stable/mariadb to mariadb-0.5.1.tgz
looping-narwha
Last Deployed: Mon Oct 17 05:21:40 2016
Namespace: default
Status: DEPLOYED

Resources:
==> extensions/Deployment
NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
looping-narwha-mariadb   1         0         0            0           0s

==> v1/PersistentVolumeClaim
NAME                     STATUS    VOLUME    CAPACITY   ACCESSMODES   AGE
looping-narwha-mariadb   Pending                                      0s

==> v1/Secret
NAME                     TYPE      DATA      AGE
looping-narwha-mariadb   Opaque    2         0s

==> v1/ConfigMap
NAME                     DATA      AGE
looping-narwha-mariadb   1         0s

==> v1/Service
NAME                     CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
looping-narwha-mariadb   20.0.0.215   <none>        3306/TCP   0s


Notes:
MariaDB can be accessed via port 3306 on the following DNS name from within your cluster:
looping-narwha-mariadb.default.svc.cluster.local

To connect to your database run the following command:

   kubectl run looping-narwha-mariadb-client --rm --tty -i --image bitnami/mariadb --command -- mysql -h looping-narwha-mariadb
**========================> After 5 minutes**

root@c910f04x19k07:~/helm/bin# kubectl get deployment
NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
looping-narwha-mariadb   1         1         1            0           5m
root@c910f04x19k07:~/helm/bin# kubectl get pods
NAME                                     READY     STATUS     RESTARTS   AGE
looping-narwha-mariadb-436722775-hss7g   0/1       Init:0/1   0          6m
root@c910f04x19k07:~/helm/bin# kubectl describe pod looping-narwha-mariadb-436722775-hss7g
Name:           looping-narwha-mariadb-436722775-hss7g
Namespace:      default
Node:           c910f04x19k08.pok.stglabs.ibm.com/10.4.19.8
Start Time:     Mon, 17 Oct 2016 05:21:41 -0400
Labels:         app=looping-narwha-mariadb
                chart=mariadb-0.5.1
                heritage=Tiller
                pod-template-hash=436722775
                release=looping-narwha
Status:         Pending
IP:
Controllers:    ReplicaSet/looping-narwha-mariadb-436722775
Init Containers:
  copy-custom-config:
    Container ID:
    Image:              bitnami/mariadb:10.1.18-r0
    Image ID:
    Port:
    Command:
      sh
      -c
      mkdir -p /bitnami/mariadb/conf && cp -n /bitnami/mariadb_config/my.cnf /bitnami/mariadb/conf/my_custom.cnf
    State:                      Waiting
      Reason:                   PodInitializing
    Ready:                      False
    Restart Count:              0
    Environment Variables:      <none>
Containers:
  looping-narwha-mariadb:
    Container ID:
    Image:              bitnami/mariadb:10.1.18-r0
    Image ID:
    Port:               3306/TCP
    State:              Waiting
      Reason:           PodInitializing
    Ready:              False
    Restart Count:      0
    Liveness:           exec [mysqladmin ping] delay=30s timeout=5s period=10s #success=1 #failure=3
    Readiness:          exec [mysqladmin ping] delay=5s timeout=1s period=10s #success=1 #failure=3
    Environment Variables:
      MARIADB_ROOT_PASSWORD:    <set to the key 'mariadb-root-password' in secret 'looping-narwha-mariadb'>
      MARIADB_USER:
      MARIADB_PASSWORD:         <set to the key 'mariadb-password' in secret 'looping-narwha-mariadb'>
      MARIADB_DATABASE:
Conditions:
  Type          Status
  Initialized   False 
  Ready         False 
  PodScheduled  True 
Volumes:
  config:
    Type:       ConfigMap (a volume populated by a ConfigMap)
    Name:       looping-narwha-mariadb
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  looping-narwha-mariadb
    ReadOnly:   false
  default-token-04890:
    Type:       Secret (a volume populated by a Secret)
    SecretName: default-token-04890
QoS Tier:       BestEffort
Events:
  FirstSeen     LastSeen        Count   From                                            SubobjectPath   Type   Reason           Message
  ---------     --------        -----   ----                                            -------------   -------------           -------
  6m            6m              1       {default-scheduler }                                            Normal Scheduled        Successfully assigned looping-narwha-mariadb-436722775-hss7g to c910f04x19k08.pok.stglabs.ibm.com
  4m            1m              2       {kubelet c910f04x19k08.pok.stglabs.ibm.com}                     WarningFailedMount      Unable to mount volumes for pod "looping-narwha-mariadb-436722775-hss7g_default(1cd9eee8-944b-11e6-b7ca-42ae0a041307)": timeout expired waiting for volumes to attach/mount for pod "looping-narwha-mariadb-436722775-hss7g"/"default". list of unattached/unmounted volumes=[data]
  4m            1m              2       {kubelet c910f04x19k08.pok.stglabs.ibm.com}                     WarningFailedSync       Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "looping-narwha-mariadb-436722775-hss7g"/"default". list of unattached/unmounted volumes=[data]


root@c910f04x19k07:~/helm/bin# 

[Stable/Drupal] add link to dependency in README

Was a bit confused when reading the README. I didn't know exactly where the "Bitnami MariaDB Chart" lived whether it was referring to the chart in bitnami repo or the stable repo. A link here would be great!

Incorrect reference to ingress ip in the jenkins chart release notes

I am using the jenkins chart to spin a jenkins instance in aws. When the instance starts the release notes https://raw.githubusercontent.com/kubernetes/charts/d745f4879e58d8c2f3a3497a7ed8e2369204f9b7/stable/jenkins/templates/NOTES.txt has reference to LB ip
export SERVICE_IP=$(kubectl get svc --namespace {{ .Release.Namespace }} {{ template "fullname" . }} -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

In aws within ingress, it is the hostname and the ip does not have value.

How can this fixed in such a way it would work both in GKE and AWS?

Zookeeper consider not using init containers

Hey all

In order to simplify the zookeeper example a bit, should we consider not using init containers? Seems a bit complicated, and I am not sure if it is adding value.

Add simple charts without PVC

While having PVs is key for real setup, for folks who get started with k8s having PV setup is not the default.

I think we need to think about charts 101 which would be charts that don't need PV. and only have volumes HostPath and EmptyDir.

PetSets are great, but we need more simple example like the mariadb one. We had a ton of them in the repo early on.

set up chart contribution

• remove all current charts (because the format is different from the helm/dm era)
• update readme with contribution process and current links
• set up CI so that a PR is green when charts are linted with no issues. This includes cleaning up _tests/
• on master green build, update google cloud storage bucket for charts with latest using helm sync-repo script

[stable/mysql] Getting pod errors

pod log output:

mysql $ k logs foiled-humming-mysql-2913034268-yllhq
Error from server: container "foiled-humming-mysql" in pod "foiled-humming-mysql-2913034268-yllhq" is waiting to start: PodInitializing

and this at the end of kubectl describe pod foiled-humming-mysql-2913034268-yllhq

 30s    6s      3       {kubelet minikube}                          Warning FailedSync      Error syncing pod, skipping: [failed to "InitContainer" for "remove-lost-found" with RunInitContainerError: "init container \"remove-lost-found\" exited with 1"
, failed to "StartContainer" for "remove-lost-found" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=remove-lost-found pod=foiled-humming-mysql-2913034268-yllhq_default(88ab61d4-97a5-11e6-a540-2ac301e229b1)"

Include how to validate install on spartickus

Update notes.txt to talk about how to validate the chat install.

Remove 'under ACTIVE development'

Now that the structure of the repository is defined, and we are syncing reliably to the hosted Chart repositories, I think we are in a more stable state and can remove this warning.

NOTES.txt loadBalancer service IP command doesn't work on AWS

On AWS, LoadBalancer services get an Elastic Load Balancer hostname (*.region.elb.amazonaws.com), so the command charts are using in their NOTES.txt returns an empty string:

kubectl get svc --namespace {{ .Release.Namespace }} {{ template "fullname" . }} -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

should be

kubectl get svc --namespace {{ .Release.Namespace }} {{ template "fullname" . }} -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

However, in GKE, you get an IP and hostname is blank so we can't switch to hostname.

We can use the following (nasty) sed to print out whatever isn't empty:

kubectl get svc --namespace {{ .Release.Namespace }} {{ template "fullname" . }} -o jsonpath='{.status.loadBalancer.ingress[0]}' | sed -E 's/.*"([^" ]+)".*/\1/'

/cc @viglesiasce @migmartri

add chart submission guidelines

issue is based off of @pwittrock's suggestion.
Feel free to add more here @pwittrock

Please ensure tests exit non-zero on test failure

Please do the same to https://github.com/kubernetes/charts/blob/master/test/changed.sh as kubernetes/test-infra#865

Create Best Practices doc

We need a place where we can establish and document best practices for chart creation. This should then be reference from the README in order to point users to this repositories conventions.

Bad label selectors queries in some incubator chart READMEs

A handful of READMEs for incubator charts have instructions with kubectl commands demonstrating label selectors that flat out don't work. For example:

https://github.com/kubernetes/charts/tree/master/incubator/etcd/README.md has a bunch of kubectl commands in it with -l "app=etcd", but that label never gets set anywhere in its template:

$ helm install --name my-release incubator/etcd
NAME: my-release
LAST DEPLOYED: Fri Oct 21 13:50:01 2016
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> apps/PetSet
NAME              DESIRED   CURRENT   AGE
my-release-etcd   3         3         0s

==> v1/Service
NAME              CLUSTER-IP   EXTERNAL-IP   PORT(S)             AGE
my-release-etcd   None         <none>        2380/TCP,2379/TCP   0s
$ kubectl get pods
NAME                READY     STATUS    RESTARTS   AGE
my-release-etcd-0   1/1       Running   0          3m
my-release-etcd-1   1/1       Running   0          3m
my-release-etcd-2   1/1       Running   0          2m
$ kubectl get pods -l "app=etcd"
$ 

Incorrect "app=" label selectors appear in other incubator charts as well, probably due to being cribbed from the etcd chart.

Separate Zepplin into another chart and not have it included in the Spark Chart

Zepplin looks crazy cool and all, but not everyone will want to deploy it with spark. It is not a core component of spark, and thus probably should not be in the chart. Split it out into a seperate chart.

Create pipeline for testing charts periodically and on PR submission

The pipeline will need to do the following (at a minimum):

• Check out the code
• Run the helm linter against the chart under test
• Deploy the chart in its own namespace
• Validate that the chart is up and running
• Push the chart to the storage bucket once it has been validated

The validation step can be very simple to begin with and get more complex as we coordinate the interface between what CI needs to implement and what Helm CLI can do (ie post install scripts/checks).

proposal: Process for signing charts (establishing provenance)

We want to be able to add provenance to all charts in this repo. The helm command has (admittedly limited) provenance tools to help with this. This proposal outlines how we could add provenance data to charts.

Fundamental Assumption: A chart with an accompanying .prov file is an assertion about the integrity of a file. Specifically:

1. The chart is crytographicly verified (hashes match, content is unaltered)
2. The chart has been reviewed and verified by the core team, and the signer has verified this
3. The signer is a person who has the authority to speak for the "official" kubernetes/charts team

The process outlined here is designed to meet each of those three expectations.

When is a Chart Signed?

A chart is signed when it has passed all of its acceptance criteria, and it is ready to be pushed to the chart repository. So the chart should be (a) passing automated tests (CI), (b) approved via LGTM or whatever human process we use, and (c) accepted as ready to release (e.g. the one who opened the request believes it is now ready for release).

At that point, one of the "core maintainers" signs the chart and commits the result to the repo.

$ helm package --sign --key "my-key" mysql
$ git add mysql-1.2.3.tgz.prov
$ ... # rest of Git workflow

(alternately: we could have the signer load the signature directly into GCS. But then it will not be tracked in revision control)

At this point, the CI/CD toolchain can actually verify that it can rebuild the package and match the .prov file before it sends the chart to the chart repository. This guarantees that we don't accidentally release a chart that is half done.

So this process addresses assumptions 1 and 2: It provides cryptographic proof that a chart is unaltered, and it asserts that someone has verified that the process of approving the chart has been completed.

How do we manage cryptographic keypairs?

Every core maintainer of the project may have one or more signing keypairs (ideally just one).

Private keys: In this model, the signer is the only one who needs the private key. So none of the "official" infrastructure needs to store private keys.

Public Keys: The public keys used to sign must be made available by the maintainer. Possible ways to make these available include mundane ways like sending them via email, or other ways like storing them in https://keybase.io (cf. https://keybase.io/technosophos).

How do we say which public keys are trusted for the kubernetes/charts repository?

We need a way to assert something like this: "The following keys are official for the kubernetes/charts repo..."

One way to do this would be to put those public keys in a well documented place that the helm tool itself could look up. It might be necessary to also cryptographically sign that information. with a "root key" or use one of the other chain of trust mechanisms popular in PKI.

As a first step, this proposal suggests that a binary keyring file called pubkeys.pgp be added to the root of the repository on GCS, and that this keyring file (temporarily) be manually managed by the team lead for the kubernetes/charts project. (That'd presumably be @prydonious)

If this is deemed sufficient, we should file an issue at https://github.com/kubernetes/helm to include support for automatically fetching and using this file to verify charts in a given repo.

So it would work like this:

1. User runs helm install charts/mysql-1.2.3
2. Helm client updates index.yaml for kubernetes/charts
3. Helm client fetches pubkeys.pgp for kubernetes/charts and caches it locally
4. Helm client fetches mysql-1.2.3.tgz and mysql-1.2.3.tgz.prov
5. Helm client cryptographically verifies mysql-1.2.3.tgz against the .prov file using ONLY the keys in the cached pubkeys.pgp file.
6. Helm installs the chart

(OPTIONAL STEP 3.5) Helm client verifies that the key used to sign is in some other chain of trust (say, local keyring or keybase.io).

How do we manage compromised/rogue keys?

Say we successfully implement this plan, but at some point a key that was used to sign numerous charts becomes compromised. What do we do?

1. The key is removed from the pubkeys.pgp file in the GCS storage. This will result in all charts signed with that key becoming untrusted. And that is good.
2. We manually re-audit all charts created with that key, and a different key is used to sign those. That different key must already be in the pubkeys file

In addition, we could provide a canonical place to post revoked keys. (perhaps revoked.pgp)

Known Weaknesses

The following are known weaknesses in this scheme:

• If the pubkeys.pgp file is compromised, we lose the entire chain of trust. This could be partially mitigated by signing the pubkeys.pgp file with a "root key" (discussed above), and having that root key managed on keybase.io or another third-party trusted key repo.
• It assumes that each individual signer will be responsible with his/her secret key files
• A full-on domain hijack of the chart repo could completely circumvent this. This is partially mitigated by an SSL certificate on the domain.

Merge helm/charts

need to merge charts from github.com/helm/charts into this one.

Rename this repo to kubernetes/charts

cc/ @vaikas-google

Add NOTES.txt for patroni chart

charts for helm v2.alpha.4+ should have a NOTES.txt to explain usage and additional information.

add a NOTES.txt for the patroni chart (#57)

Change format of existing dm templates

update format of existing dm templates to new format

MariaDB no resource limits or requests

https://github.com/kubernetes/charts/blob/master/stable/mariadb/templates/deployment.yaml

No resource usage settings :(

More options for Spark Chart such as worker HEAP size

Allow for more tweaks with memory and other options with Spark workers and master. Since we are using the Spark release and not the Cloudera release we need to find the correct docs. Here are the docs from Cloudera to give us an outline of what I am referring to.

http://www.cloudera.com/documentation/manager/5-1-x/Cloudera-Manager-Configuration-Properties/cm5config_cdh400_spark.html

Change Expander.Name from Expandybird to expandybird-service in charts with DM templates

Setup a contrib charts repo

As discussed previously (in charts chats and Helm developer calls), we'd like to setup a separate GitHub and Chart repository for charts that may not meet the bar for this repository. These could include charts that are:

• Examples for new features, ideas
• Scaffolds that may require editing the chart templates to get started
• Using alpha Kubernetes features, or third-party extensions

/cc @erictune @viglesiasce @michelleN

MariaDB with custom configuration extensions

I have to supply MariaDB with custom configuration extensions/overrides. For example:

[mysqld]
max_allowed_packet = 64M
sql_mode=STRICT_ALL_TABLES
ft_stopword_file=/etc/mysql/stopwords.txt
ft_min_word_len=3
ft_boolean_syntax=' |-><()~*:""&^'
innodb_buffer_pool_size=2G

How do I do this with the MariaDB Chart?

Consul Chart Improvements

Since we are running a Petset should we include notes about deleting storage when we delete the Petset?