search

vmware-tanzu / package-for-kubeapps

This repo will house the carvel tooling specific configuration and templating for a deployment of Kubeapps (https://github.com/vmware-tanzu/kubeapps) that will be leveraged by TCE
Apache License 2.0
5 stars 0 forks source link

Consider providing different default values for the Carvel package #6

Closed absoludity closed 2 years ago

absoludity commented 2 years ago

We need to decide whether this is worthwhile. By default, Kubeapps installs with Helm support and not carvel support. Additionally when installing on TCE (or a cluster with contour) we need to add an HTTPProxy contour object to avoid contour interpreting the grpc-web requests for us.

Not sure if this would be worthwhile, or just leaving to users to set the values. I'm leaning toward the latter but keen to hear what others think. We'd need to update the default values before generating the schema and possibly regenerating the readme etc., which starts adding skew between the carvel and helm packages.

absoludity commented 2 years ago

We need to decide whether this is worthwhile. By default, Kubeapps installs with Helm support and not carvel support. Additionally when installing on TCE (or a cluster with contour) we need to add an HTTPProxy contour object to avoid contour interpreting the grpc-web requests for us.

So thinking about this a bit more, I think the first is definitely worth doing in the carvel package (and can be done such that the readme and schema reflect this). I'm not sure that the second should be done in the package itself (prefer not to).

absoludity commented 2 years ago

In #15 we added both the update to the values.yaml (and re-generation of the readme and schema) so that carvel is enabled by default, as well as adding a separate ytt stage in the template pipeline so any user-specific overlays can be included.