{"action":"created","issue":{"url":"https://api.github.com/repos/kubernetes/helm/issues/3431","repository_url":"https://api.github.com/repos/kubernetes/helm","labels_url":"https://api.github.com/repos/kubernetes/helm/issues/3431/labels{/name}","comments_url":"https://api.github.com/repos/kubernetes/helm/issues/3431/comments","events_url":"https://api.github.com/repos/kubernetes/helm/issues/3431/events","html_url":"https://github.com/kubernetes/helm/issues/3431","id":293440184,"number":3431,"title":"Expose chart's expected values to users","user":{"login":"itaysk","id":1161307,"avatar_url":"https://avatars0.githubusercontent.com/u/1161307?v=4","gravatar_id":"","url":"https://api.github.com/users/itaysk","html_url":"https://github.com/itaysk","followers_url":"https://api.github.com/users/itaysk/followers","following_url":"https://api.github.com/users/itaysk/following{/other_user}","gists_url":"https://api.github.com/users/itaysk/gists{/gist_id}","starred_url":"https://api.github.com/users/itaysk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/itaysk/subscriptions","organizations_url":"https://api.github.com/users/itaysk/orgs","repos_url":"https://api.github.com/users/itaysk/repos","events_url":"https://api.github.com/users/itaysk/events{/privacy}","received_events_url":"https://api.github.com/users/itaysk/received_events","type":"User","site_admin":false},"labels":[{"id":335802899,"url":"https://api.github.com/repos/kubernetes/helm/labels/proposal","name":"proposal","color":"0052cc","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-02-01T08:18:02Z","updated_at":"2018-03-07T23:35:47Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"I think it will be beneficial for users to know the expected values files of a chart they are about to install, before they install it.\r\n\r\nThis is presumably solved by `helm inspect values` which is supposed to help the user understand what values are expected by the chart, but currently it just shows the contents of the `values.yaml` file. The problem with this implementation is that:\r\n- the values file may not exist (it's optional according the our standard).\r\n- the contents of values file are not required to cover all variables expected by the template.\r\n\r\nI can think of several solutions:\r\n- re-implementation of `helm inspect values` to crawl template files and extract values using regex.\r\n- as part of the chart standard, define the `values.yaml` file as essential to charts, mandatory and complete.\r\n- make all values required by default (in practice most charts in the wild think this way), and replace the `required` template function with another function to opt out.\r\n- introduce a new construct as part of the chart metadata. related to: https://github.com/kubernetes/helm/issues/1098#issuecomment-359436138\r\n\r\nInterested in your opinion. I am willing to implement the solution if we can agree on one."},"comment":{"url":"https://api.github.com/repos/kubernetes/helm/issues/comments/371324221","html_url":"https://github.com/kubernetes/helm/issues/3431#issuecomment-371324221","issue_url":"https://api.github.com/repos/kubernetes/helm/issues/3431","id":371324221,"user":{"login":"phemmer","id":1826947,"avatar_url":"https://avatars3.githubusercontent.com/u/1826947?v=4","gravatar_id":"","url":"https://api.github.com/users/phemmer","html_url":"https://github.com/phemmer","followers_url":"https://api.github.com/users/phemmer/followers","following_url":"https://api.github.com/users/phemmer/following{/other_user}","gists_url":"https://api.github.com/users/phemmer/gists{/gist_id}","starred_url":"https://api.github.com/users/phemmer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/phemmer/subscriptions","organizations_url":"https://api.github.com/users/phemmer/orgs","repos_url":"https://api.github.com/users/phemmer/repos","events_url":"https://api.github.com/users/phemmer/events{/privacy}","received_events_url":"https://api.github.com/users/phemmer/received_events","type":"User","site_admin":false},"created_at":"2018-03-07T23:35:47Z","updated_at":"2018-03-07T23:35:47Z","author_association":"NONE","body":"My own thoughts I figured I'd add here rather than creating a new issue:\r\n\r\nI think it would be good to show the values of subcharts as well. Right now if you install a chart that has subcharts, you have to manually crawl the dependency tree to find all the required values (as mentioned, assuming they're documented in values.yaml).\r\n\r\n----\r\n\r\nThoughts on the existing proposal\r\n\r\n> re-implementation of helm inspect values to crawl template files and extract values using regex.\r\n\r\nI don't think regex would be a good solution. This is akin to parsing xml with regex, [and we all know how that goes](https://stackoverflow.com/a/1732454/486035).\r\n\r\n&nbsp;\r\n\r\n> as part of the chart standard, define the values.yaml file as essential to charts, mandatory and complete.\r\n\r\nThere's nothing preventing someone from just creating an empty file. I think we need something that can be verified by a code.\r\n\r\n&nbsp;\r\n\r\n> make all values required by default (in practice most charts in the wild think this way), and replace the required template function with another function to opt out.\r\n\r\nWhile I might agree with making vars required by default. I don't see how this relates to the exposed documentation of them.\r\n\r\n&nbsp;\r\n\r\n> introduce a new construct as part of the chart metadata.\r\n\r\nI think something along these lines would work, but instead of just an opaque blob of text, actually have something machine parsable. I think this is going to be the only reasonable way to  handle the subchart issue since a chart might have the value `foo`, but once it becomes a subchart of the chart `bar`, the value (as exposed to the user) becomes `bar.foo`. Thus helm would have to recursively handle all the subcharts, and properly scope/prefix all the variable names.\r\n\r\nIf we want to maintain compatibility with the current value.yaml, we could do something like:\r\n```\r\nfoo#description: This is foo\r\nfoo: bar\r\n```\r\nOr any way of adding an additional key to the yaml and deterministically relating it to the actual value name. And then something which isn't likely to collide with valid value names (hence my use of `#` in above example).\r\n\r\n&nbsp;\r\n\r\n> the contents of values file are not required to cover all variables expected by the template.\r\n\r\nI think this one is a little hairy to enforce. The only possible way I can see to do it would be to use https://golang.org/pkg/text/template/parse/ to actually parse the template files, and look for `.Value.` references.\r\n\r\nThis might be a good start for a helm linter."}}
{"actor":{"display_login":"phemmer"}}