Closed slack closed 8 years ago
I think adding a required parameter reduces a bit of the magic that a helm install
gives users. If at all possible, we should have default commands (with no parameters) that "just work."
Why not just use separate namespaces?
Related: https://github.com/kubernetes/kubernetes/issues/1698
Why not just use separate namespaces?
We do offer namespace parameterization. However, we also want to allow for multiple instances of a chart (Redis) to live in the same namespace. The group
label convention allows for multiple provider
s to co-exist in the same namespace -- analogous to a tier
label.
I am not totally convinced that we need to make group
mandatory for Helm to work. This imposes an unnecessary burden on the simple-case user. It also enforces a part of "our model" that not all users will find they want to participate in.
I'd rather develop more of a use case than rush to implement this as described here.
I'm supportive of adding some automatic label management to Kubernetes.
The future of Helm is at kubernetes/helm. Helm Classic is in maintenance mode, so I'm closing this enhancement request.
We need to make sure folks who deploy more than one instance of a helm chart into a single namespace don't end up getting very confusing results.
For example, if I have two instances of
redis-standalone
in thedefault
namespace and I use a simple label selector ofprovider=redis
my application will be automatically load balanced between all redis instances.We should probably make
group=...
parameter required.