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

Open
#126 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
helm, kubernetes

Research direction

Review PR #124 and the Helm chart templates that define namespaces, RBAC resources, and environment variables. Compare namespace-scoped and cluster-scoped deployments, then verify that an unset or explicit rbacScope produces the corresponding Role/RoleBinding or ClusterRole/ClusterRoleBinding behavior without requiring per-namespace values files.

Written by the indexing model from the issue text.

Description

In https://github.com/coder/coder-logstream-kube/pull/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.

Dominant language
Go
Stars
28
Forks
9
Avg merge
7d 11h
Merged PRs (30d)
6

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from coder/coder-logstream-kube

All issues in coder/coder-logstream-kube

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.