Repository navigation
Conversation
When hub.existingSecret is set, the chart managed hub Secret is no longer rendered. Hub and proxy pods read CONFIGPROXY_AUTH_TOKEN and all other tokens directly from the user managed Secret via the existing jupyterhub.hub-existing-secret-or-default.fullname helper. The checksum/secret annotation on the hub Deployment is omitted when hub.existingSecret is set, preventing spurious rolling restarts caused by non-deterministic token generation during Helm rendering without cluster access (e.g. ArgoCD, helm diff). Previously hub.existingSecret only supplemented the chart managed Secret at runtime (via the /existing-secret/ volume mount), while CONFIGPROXY_AUTH_TOKEN was always sourced from the chart managed Secret. This meant the chart still generated random tokens on every render, defeating the purpose of providing stable tokens via an external Secret. The user managed Secret must contain: hub.config.ConfigurableHTTPProxy.auth_token hub.config.JupyterHub.cookie_secret hub.config.CryptKeeper.keys hub.services.<name>.apiToken (one per configured service)
The 'secret' volume in the hub Deployment previously always referenced the chart-managed Secret by name. When hub.existingSecret is set and the chart-managed Secret is not rendered, the volume mount would fail because the referenced Secret no longer exists. Use the hub-existing-secret-or-default.fullname helper so the secret volume resolves to the user-managed Secret when hub.existingSecret is set.
Skipping the entire hub Secret broke hub.extraFiles: the files volume mounts Secret content that the chart generates, which is unrelated to the random token problem. Instead, only guard the token keys (auth_token, cookie_secret, CryptKeeper.keys, service apiTokens) with the existingSecret condition. The Secret is still rendered with values.yaml, db.password and extraFiles content — all deterministic. The checksum/secret annotation now stabilises when existingSecret is set. Also revert the secret volume secretName to hub.fullname; the chart Secret is always present so the -or-default helper is not needed there.
When hub.existingSecret is set, the chart no longer writes service apiTokens to the chart-managed Secret. The test infrastructure reads these from the user-managed Secret, so they must be present there.
Contributor
Author
|
Closes #2887 |
test-explicit-name and test-generation-of-apiToken were also missing.
The checksum/auth-token annotation is computed from the auth token value via a helper that falls back to randAlphaNum when lookup() returns nil. In GitOps tools like ArgoCD, lookup() always returns nil, so the checksum changes on every render and rolls the proxy pod on every reconcile. When hub.existingSecret is set the user manages the auth token outside the chart. Drop checksum/auth-token in that case so the proxy is only restarted by actual pod spec changes. Users who want automatic restarts on token rotation can use Stakater Reloader or similar tools.
Member
|
Sorry for the delay! I think this makes sense. It is a breaking change because the docs say it will be merged and given highest priority, whereas this changes it to require being exclusively used, so prior I think that's okay, we just need to update the schema so this change shows up in documentation. |
|
I have been having an issue with exactly this behaviour and would love to see this released. @erwinschliske I am happy to update the docs if you don't have time, as this is quite urgent for us. |
minrk
changed the title
consideRatio
pushed a commit
to jupyterhub/helm-chart
that referenced
this pull request
Oct 21, 2026
jupyterhub/zero-to-jupyterhub-k8s#3903 Merge pull request #3903 from erwinschliske/fix/hub-existing-secret-full-replacement
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When
hub.existingSecretis set, the chart still renders its own hub Secretwith randomly generated tokens. In ArgoCD/GitOps setups where
lookup()hasno cluster access, these tokens change on every render, which rolls the hub pod
on every reconcile.
This PR makes
hub.existingSecretactually replace the token keys:existingSecretis set (values.yaml, db.password and extraFiles are still rendered — those are deterministic and needed for volume mounts)CONFIGPROXY_AUTH_TOKENin hub and proxy Deployments to the user-managed Secretchecksum/secretannotation now stabilises because the hub Secret no longer contains random valuesThe
hub-existing-secret-or-defaulthelper already existed — it just wasn'twired up in the right places.
No change when
hub.existingSecretis not set.