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

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?

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.

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

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

No resource usage settings :(

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

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

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?

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

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?

cc/ @vaikas-google

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

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

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.

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

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.

update format of existing dm templates to new format

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

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.

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.

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

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.

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

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

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

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?

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.

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.

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.

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

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

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

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

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.

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.

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

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# 

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

depends on #6

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

• 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

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!

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.

• 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

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)

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.

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

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.

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

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