[bug]: v0.0.12 helm chart now requires that you pass in your own namespace

[diranged]

In #124 you now must pass in your own namespace as a parameter to the helm chart if you don't want to create a ClusterRole and ClusterRoleBinding. This is rough from a GitOps perspective, because it means that you have two choices (in an environment where applications are not allowed to create cluster-scoped resources):

1. You create values.<something>.yaml files where you set namespaces: [ my-coder-ns ] and launch the application with custom values files for each namespace you put it in.
2. When you launch the application you pass in --set namespaces=...

In my opinion, if namespaces is not set, then there should be a simple setting of rbacScope: <namespace|cluster> ... and if it is set to namespace then the RBAC permissions created with Role/RoleBindings (and NAMESPACES=${{ .Release.Namespace}} is set as an env variable). If it is set to cluster, then you create ClusterRole/ClusterRoleBindings.

[deansheather]

This is rough from a GitOps perspective

@diranged can you elaborate more on this? It seems like it would be simple to set the values in your gitops configuration for the helm deployment

[deansheather]

BTW, if you specify multiple namespaces in a single deployment, it creates a Role + RoleBinding for each namespace. We only use a ClusterRole + ClusterRoleBinding when no namespaces are specified.

[diranged]

BTW, if you specify multiple namespaces in a single deployment, it creates a Role + RoleBinding for each namespace. We only use a ClusterRole + ClusterRoleBinding when no namespaces are specified.

So in the ArgoCD world, it's pretty common to use the "app of apps" model. We have a common helm chart that itself launches every single other ArgoCD application in the company (hundreds), and it does this across dozens of clusters. The developers are in control of the source of the source code, the name of the application, and the target cluster/namespace ... but all other customizations are handled inside their own repo via values files.

So to launch Coder multiple times on a single cluster, things get really tricky because our top level app-of-apps model is specifically designed to be void of any application-specific configuration. That's all meant to live in the developers repositories.

I don't disagree with the option of having a Values.namespaces key ... but I don't think that it should be the default pattern. In my opinion the original default pattern was the most sane. Generally applications are namespace-scoped when they are launched, and having the chart default to a namespace scoped installation makes sense. Allowing it to auto-detect the namespace it's in also makes sense as a default behavior.

(on a side note.. a similar frustration for me is when people create a .Values.namespace parameter, and then use namespace: ${{ .Values.namespace }} as opposed to namespace: ${{ .Release.Namespace }} or even simply avoiding defining the namespace key all together on namespace-scoped resources).