Charts: Some chart `values.yaml` include comment out parameters

[gyliu513]

Is this a request for help?:

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

Version of Helm and Kubernetes:

Which chart:
Charts which have some comment out parameters, such as stable/grafana, stable/prometheus etc.

What happened:
Take grafana as an example, it is defining the storageClass as comment out here https://github.com/kubernetes/charts/blob/master/stable/grafana/values.yaml#L84

    ## Data Persistent Volume Storage Class
    ## If defined, volume.beta.kubernetes.io/storage-class: <storageClass>
    ## Default: volume.alpha.kubernetes.io/storage-class: default
    ##
    # storageClass:

And the pvc just checking the logic as this https://github.com/kubernetes/charts/blob/master/stable/grafana/templates/pvc.yaml#L7-L10

  {{- if .Values.server.persistentVolume.storageClass }}
    volume.beta.kubernetes.io/storage-class: {{ .Values.server.persistentVolume.storageClass | quote }}
  {{- else }}
    volume.alpha.kubernetes.io/storage-class: default

If someone want to develop a dashboard for those helm charts and get values from values.yaml, it may got some problem for those comment out parameters, as those parameters cannot be got from the values.yaml and thus cannot be listed on the customized dashboard, this caused the end user cannot customize those parameters.

For such case, if encounter some deprecated parameters, the chart deploy will be failed. Take stable/grafana as example, as the customized helm dashboard cannot get the comment out storageClass from values.yaml, and this caused all of the charts cannot set the storageClass and always use default, the default volume.alpha.kubernetes.io/storage-class has been deprecated since Kubernetes 1.3, this caused all of the charts which have storageClass will always failed to deploy.

What you expected to happen:
Do not comment out parameters in values.yaml but always give some default parameters instead.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know:

[gyliu513]

/cc @kubernetes/helm-maintainers any comments for this?

[dmccaffery]

@gyliu513 : this is by design... they are commented out as they aren't necessary for a default deployment. If you want to specify your own storage class (or any other value), you can use the --set cli argument to override individual values, or specify your own .yaml file containing the custom config using --values cli argument.

Keep in mind that these can be repeated, and the right most parameter will supersede others (if they specify the same settings).

[gyliu513]

@dmccaffery thanks, but the problem is that if I want to read those parameters from dashboard, then I cannot get the parameters which are comment out, thus the dashboard will have no chance to set those parameters, but with CLI, I can always use --set to set the parameters. Any comments for how to handle the case if I read the values.yaml and how to get the values which are comment out?

[gyliu513]

Any comments for how to enable the dashboard to get those commented out keys from values.yaml? @kubernetes/helm-maintainers @dmccaffery

[kfox1111]

We've talked about duplication of documentation in NOTES.txt, readme.rst and values.yaml... I'd kind of like to see the possible values with comments stored in a machine readable format somewhere and generate parts of NOTES/readme from it. Would also allow a web ui and cli to display better options too. Someone should probably raise this issue again at the dev meeting?

[gyliu513]

@kfox1111 is there a link where can I put this to the agenda of dev meeting? Want to raise this issue so that we can fix this soon.

[kfox1111]

@gyliu513 some discussion in this issue: https://github.com/kubernetes/charts/pull/804
Not sure where else.

[gyliu513]

@kfox1111 seems there are some misunderstanding here, my issue is as following: I have a customized kubernetes UI which can enable end users configure the parameters from values.yaml, but if the parameters comment out in values.yaml, then I will not able to display them on UI and thus user is not able to configure those parameters, this will cause some issues, such as storageClass, as I cannot enable end user to configure storageClass in the dashboard, then the chart will always use volume.alpha.kubernetes.io/storage-class: default, this will cause some errors when using kubernetes 1.6/1.7 as the parameter volume.alpha.kubernetes.io/storage-class: default has been deprecated.

[prydonius]

+1 to @kfox1111, I want to see a javadoc style format adopted for values.yaml so that all values and associated documentation is machine readable. Once we have this it can pave the way for supporting values in Monocular (https://github.com/kubernetes-helm/monocular/issues/245) as well as other tools.

[kfox1111]

@gyliu513 I guess I'm arguing what you want to do is a subset of a greater problem of needing a way to get possible values, not just the defaults to users and software. Readme/notes are just another relay mechanism today that isn't very maintainable/easy to use.

[gyliu513]

@kfox1111 yes, that make sense, thanks.

[prydonius]

@gyliu513 @kfox1111 closing this particular issue, but if it would be good to chat more about a machine-readable values.yaml format in a future charts meeting (see #charts in slack) or sig-apps meeting.