Allow to use several values.yaml files (i.e. for different environments)

[andresmgot]

We include a second values.yaml on infrastructure charts with values that are supposed to be “production ready”.
It would be good if this file is also shown by Kubeapps.

cc/ @beltran-rubo @juan131

[prydonius]

To clarify, this is something that the Bitnami charts offer (e.g. https://github.com/helm/charts/blob/master/stable/mongodb/values-production.yaml). This file is available in the chart package (not in Helm ignore), so we are able to extract it from the chart-repo tool. In the UI, I think we can show a button for "Default" or "Production-optimized" above the values input if we detect a values-production.yaml file in a Chart.

The only reason that we might not want to do this, is that it's not really an adopted standard by the community and only the Bitnami charts implement it (which is not very surprising because there isn't a good way to use and discover the production values using the Helm CLI). That said, I think it does add value to Bitnami chart users in Kubeapps.

[prydonius]

I think we can do a better job of publicising what guidelines the Bitnami charts follow to provide some insight, reasoning and help the community adopt some of the interesting things we're doing with charts. Created bitnami/charts#959.

[fudali113]

I think it's not just production environments, what if we have multiple environments? Can values-*.yaml be supported?

[prydonius]

@fudali113 interesting idea, do you have any examples of charts that have other values-*.yaml files today?

[RomanGz]

+1

Would be great to be able to specify which values file to use like you can with helm cli. Having one chart, but different values templated into configmaps for dev/qa/prod, etc.

[fudali113]

@fudali113 interesting idea, do you have any examples of charts that have other values-*.yaml files today?

my use cases like with @rgazaryants

Would be great to be able to specify which values file to use like you can with helm cli. Having one chart, but different values templated into configmaps for dev/qa/prod, etc.

@prydonius

[prydonius]

So the idea here would be to save sets of values files (in a configmap, or CRD or something) and then be able to choose from them to apply during deployment? Sort of like templates you can save and reuse?

[fudali113]

yes, choose and not input. reduce error rate

[alexandredantas]

@prydonius I'm willing to contribute with this feature. Currently, I'm working on Gympass and we are needing this feature. Is that ok?

[absoludity]

Hi @alexandredantas . There's been a few options on this thread... but one of the key factors is that this isn't (yet?) a standard property of helm charts, so yes we can update Kubeapps to check for multiple values.yaml files when importing charts so that when displaying charts for install we can include a selector if (and only if) there are multiple?

If you're keen, can you do a PR with a brief design proposal of what you're thinking/planning in https://github.com/kubeapps/kubeapps/tree/master/docs/architecture/design-proposals ? Thanks!

[alexandredantas]

@absoludity sure, I'm preparing a design proposal. Soon I will commit it to be reviewed. Thanks!

[gkulkarni32]

Hello,
Interesting proposal on the having multiple values-*.yaml available on kubeApps portal. It would be great value add to have other values-*.yaml files displayed if they are detected. Is the development already in progress for this?

Thanks
Geeta

[andresmgot]

Hi @gkulkarni32, there has not been progress related to this. It's still not clear how useful this would be since there is no standard related to this. Also, the Bitnami team has stopped supporting several values files (see bitnami/charts#5095).

[frank-bee]

@gkulkarni32 I think there is no standard neither in helm nor at bitnami.

For our usecase here in my company it would be anyway better to configure the value file(s) either in the kubeapps frontend or when deploying kubeapps (the latter would be enough).

Could be done via another CRD or in the database: allowing to configure apps ( not app repositories ).
Unfortunately for each version of an app may have different value file (s).
The CRD could be uses to overwrite the values file of an app or add a values file to the app ( if multiple value files should be supported). The CRD could contain something like an expression / regex to define for which repo + app + version a value file is contributed.

[frank-bee]

I found another interesting approach to handle user customized values:
https://codefresh.io/docs/docs/configure-ci-cd-pipeline/shared-configuration/#using-shared-helm-values

The user can create "value file snippets" (basically yaml files) and use these during helm install / upgrade.

Could be rather simple and flexible, not?

[absoludity]

@gkulkarni32 I think there is no standard neither in helm nor at bitnami.

For our usecase here in my company it would be anyway better to configure the value file(s) either in the kubeapps frontend or when deploying kubeapps (the latter would be enough).

So I think you mean that when deploying, you'd tell Kubeapps that you want to use a different values.yaml file (such as production-values.yaml) which exists in the chart?

Could be done via another CRD or in the database: allowing to configure apps ( not app repositories ).
Unfortunately for each version of an app may have different value file (s).
The CRD could be uses to overwrite the values file of an app or add a values file to the app ( if multiple value files should be supported). The CRD could contain something like an expression / regex to define for which repo + app + version a value file is contributed.

I don't think a CRD is a good candidate for storing config/state like that. A configmap or secret perhaps, if you mean to associate extra config (such as values.yaml) with a specific chart from a specific repo.

I found another interesting approach to handle user customized values:
https://codefresh.io/docs/docs/configure-ci-cd-pipeline/shared-configuration/#using-shared-helm-values

The user can create "value file snippets" (basically yaml files) and use these during helm install / upgrade.

Could be rather simple and flexible, not?

Depends - seems very different to what you'd originally proposed. It's not clear to me whether you mean several values.yaml options in a chart, or you mean adding values.yaml options for an already published chart? If it's the latter, although yes, you can imagine something like configmaps/secrets being used to define extra values.yaml that could be presented in the Kubeapps UI (when installing a certain chart), they'd be a maintainers nightmare, I think? How would you keep them up to date when a new chart is released, or would you create them per chart version?

Let me know if that's what you're thinking.

[frank-bee]

So I think you mean that when deploying, you'd tell Kubeapps that you want to use a different values.yaml file (such as production-values.yaml)

Correct, that's what we need in our current scenario

...which exists in the chart?

That could be an option.
But in our case the chart itself is open source but the values we use in our deployments are pretty company specific (URLs, CSS styling,..).
That's why I'm thinking if there is a ways to allow a "kubeapps admin" to define these values (Remark: "kubeapps admin" whould be a different persona than the one that deploys the helm charts).
But you are right, could be a maintainers nightmare (the nightmare of this "kubeapps admin").

you can imagine something like configmaps/secrets being used to define extra values.yaml that could be presented in the Kubeapps UI

That would be an option. But it might be difficult to map such a configmap to a chart version or a set of versions (flexible, maintainable). Maybe the user could load / select any kinds of configmaps in the selected namespace (or the ones tagged with a special tag like "value file".

[absoludity]

As part of our work generalising Kubeapps to support other packaging formats, we'll need to enable selecting other values specifically from config maps or secrets in the namespace, for use during deploy (as, for example, flux enables this with its ValuesReference struct). It won't be supported immediately, but I assume we will be working towards that, and when generalised, it can be available for the direct helm case also.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[absoludity]

JFYI, one of the cases here, where the package itself includes the custom default values, has been implemented as part of the separate issue #5692 . I'll leave this issue here open, since IMO it also includes the other options (such as being able to customise the default values without updating the package), and move it back to the backlog until we do that work.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[absoludity]

JFYI, one of the cases here, where the package itself includes the custom default values, has been implemented as part of the separate issue #5692 . I'll leave this issue here open, since IMO it also includes the other options (such as being able to customise the default values without updating the package), and move it back to the backlog until we do that work.

Actually, the functionality in the latest release implements the original case for this issue: enabling Kubeapps to pick up and display multiple default values files when they are provided in the chart. The extra cases added later for supporting the ability to add these at run-time will be tracked in a separate issue.