-
- Downloads
update use of namespaces in chart (#62)
To ensure Helm releases are installed in the desired namespace it is important to always specify the release namespace: helm install -n <namespace>. This MR fixes the chart so it will follow this approach (which is the standard way since I think Helm 3 at least), instead of using a value to control the namespace. If you helm install without -n it is the same as using kubectl without -n, it should use the default namespace configured in the current context of your kubeconfig. However the current non-standard behaviour of the chart (which I would argue is a bug) overrides this to end up in kube-system instead of whatever your current default is - IF the user doesn't specify it with -n (but you really should). Actually the more serious bug is that the current values-based namespace selection could potentially prevent the standard release-based namespace selection mechanism from working at all, so a user doing the right thing (helm install -n mynamespace) would potentially end up with the helm release details going in the right namespace and the k8s objects going in the wrong namespace, I am not sure how that would work. fix #60 Also: There is no such thing as a namespace for a ClusterRoleBinding, k8s ignores it. Remove 'default' There is no reason to be granting RBAC privileges to the default service account in the default namespace, removed
Showing
- helm/amd-gpu/README.md 0 additions, 1 deletionhelm/amd-gpu/README.md
- helm/amd-gpu/templates/NOTES.txt 2 additions, 2 deletionshelm/amd-gpu/templates/NOTES.txt
- helm/amd-gpu/templates/deviceplugin-daemonset.yaml 0 additions, 1 deletionhelm/amd-gpu/templates/deviceplugin-daemonset.yaml
- helm/amd-gpu/templates/labeller.yaml 1 addition, 6 deletionshelm/amd-gpu/templates/labeller.yaml
- helm/amd-gpu/values.yaml 0 additions, 2 deletionshelm/amd-gpu/values.yaml
Loading
Please register or sign in to comment