Problem
After PR #74 flipped rbac.bootstrap.enabled: true as the chart default, the post-install/upgrade RBAC bootstrap Job started failing on real deployments with:
==> 2. hub OIDC client + service account
Traceback (most recent call last):
File "/scripts/keycloak_rbac_bootstrap.py", line 521, in <module>
sys.exit(main())
File "/scripts/keycloak_rbac_bootstrap.py", line 265, in get_client_uuid
raise RuntimeError(
RuntimeError: client 'jupyterhub-data-science-pack-nebari-data-science-pack' not found in realm 'nebari'
Root cause
The chart's values.yaml documents the auto-derive behavior:
ClientId of the hub OAuth client in Keycloak (created by the nebari-operator NebariApp). Leave empty to derive from the release + chart name (the operator's standard pattern: jupyterhub-<release>-<chart>). Override for non-standard client ids.
That assumption doesn't match the operator. nebari-operator actually builds the client id as <namespace>-<release>-<chart> — it uses the NebariApp's namespace as the prefix, not the literal string jupyterhub. So for a release data-science-pack of chart nebari-data-science-pack in namespace nebari-system, the operator provisions:
nebari-system-data-science-pack-nebari-data-science-pack
…but the chart's auto-derive produces:
jupyterhub-data-science-pack-nebari-data-science-pack
The two only agree when the NebariApp lives in a namespace literally named jupyterhub, which I'd guess only matches local-dev k3d clusters (which is plausibly where the assumption was first formed).
Fix
Replace the literal in the derivation with .Release.Namespace. Concretely in templates/keycloak-rbac-bootstrap-job.yaml (and any helper that owns the derivation):
- name: HUB_CLIENT_ID
value: {{ default (printf "%s-%s-%s" .Release.Namespace .Release.Name .Chart.Name) .Values.rbac.bootstrap.hubClientId | quote }}
…and update the values.yaml comment to say "derive from .Release.Namespace-.Release.Name-.Chart.Name (the operator's standard pattern)".
Cluster impact (real deployment hitting this)
NIC's Hetzner cluster sync moved past e987b6d (alpha.12) to the merged PR #74 (0cdf3f2). The RBAC Job failed every post-sync run with the error above until we explicitly set rbac.bootstrap.hubClientId to the operator-provisioned name in deployment-level values (see openteams-ai/nic-deploy#12 for the workaround).
Every deployment using nebari-operator + a namespace that isn't named jupyterhub will hit this on first chart sync after the default flipped.
Related upstream change request
Even with this fix, the chart's RBAC Job is a workaround for a CRD gap on the operator side — NebariApp.auth.keycloakConfig supports groups and protocol mappers but not client roles. Tracked at nebari-dev/nebari-operator#119. Once that lands, the whole Job can go.
Problem
After PR #74 flipped
rbac.bootstrap.enabled: trueas the chart default, the post-install/upgrade RBAC bootstrap Job started failing on real deployments with:Root cause
The chart's
values.yamldocuments the auto-derive behavior:That assumption doesn't match the operator.
nebari-operatoractually builds the client id as<namespace>-<release>-<chart>— it uses the NebariApp's namespace as the prefix, not the literal stringjupyterhub. So for a releasedata-science-packof chartnebari-data-science-packin namespacenebari-system, the operator provisions:…but the chart's auto-derive produces:
The two only agree when the NebariApp lives in a namespace literally named
jupyterhub, which I'd guess only matches local-dev k3d clusters (which is plausibly where the assumption was first formed).Fix
Replace the literal in the derivation with
.Release.Namespace. Concretely intemplates/keycloak-rbac-bootstrap-job.yaml(and any helper that owns the derivation):…and update the
values.yamlcomment to say "derive from.Release.Namespace-.Release.Name-.Chart.Name(the operator's standard pattern)".Cluster impact (real deployment hitting this)
NIC's Hetzner cluster sync moved past
e987b6d(alpha.12) to the merged PR #74 (0cdf3f2). The RBAC Job failed every post-sync run with the error above until we explicitly setrbac.bootstrap.hubClientIdto the operator-provisioned name in deployment-level values (seeopenteams-ai/nic-deploy#12for the workaround).Every deployment using
nebari-operator+ a namespace that isn't namedjupyterhubwill hit this on first chart sync after the default flipped.Related upstream change request
Even with this fix, the chart's RBAC Job is a workaround for a CRD gap on the operator side —
NebariApp.auth.keycloakConfigsupports groups and protocol mappers but not client roles. Tracked at nebari-dev/nebari-operator#119. Once that lands, the whole Job can go.