Add explicit namespace fields for ArgoCD/FluxCD compatibility

[duncan-i3-work]

Summary

Adds explicit namespace: field to all namespaced Kubernetes resources and introduces namespaceOverride configuration following the Bitnami chart pattern. This improves ArgoCD/FluxCD compatibility and enables custom namespace deployments.

Addresses

Addresses #3396 - Improves ArgoCD/FluxCD compatibility for GitOps deployments

Related to #3190 - Makes multi-namespace deployments more reliable

Changes

Configuration

• Adds namespaceOverride field to values.yaml
• Adds comprehensive documentation to values.schema.yaml
• Adds jupyterhub.namespace helper function in _helpers.tpl
• Updates README.md with usage documentation

Resources Updated (45 namespaced resources)

Adds explicit namespace: {{ include "jupyterhub.namespace" . }} to all namespaced resources:

• 3 ConfigMaps
• 4 Secrets
• 4 Services (including 2 in proxy/service.yaml)
• 6 ServiceAccounts
• 4 Deployments
• 1 StatefulSet
• 2 DaemonSets (via helper template)
• 1 Job
• 3 Roles
• 3 RoleBindings (+ subject namespace fields)
• 5 PodDisruptionBudgets
• 4 NetworkPolicies
• 1 PersistentVolumeClaim
• 1 Ingress
• 1 HTTPRoute

Special References Updated (11 locations)

Replaces all .Release.Namespace references with helper function:

• 4 RoleBinding subject namespaces
• 1 Job command argument
• 1 ConfigMap data field (user-scheduler config)
• 3 PriorityClass annotations
• 5 lookup functions (in helper templates)

Cluster-Scoped Resources

• ClusterRole, ClusterRoleBinding: Correctly have no namespace field
• PriorityClass (3): Annotations updated to use helper function

Benefits

ArgoCD/FluxCD Compatibility

• Explicit namespace fields enable proper resource tracking in GitOps tools
• Resolves issues where ArgoCD cannot track resources without explicit namespaces

Multi-Namespace Support

• Allows deploying chart resources to a namespace different from the Helm release namespace
• Enables multiple JupyterHub deployments with better namespace isolation

Subchart Scenarios

• Parent charts can override the namespace for child chart resources
• Follows industry standard patterns (Bitnami, etc.)

Backward Compatibility

✅ Fully backward compatible - defaults to .Release.Namespace when namespaceOverride is not set

Usage

Deploy all resources to a custom namespace:

# values.yaml
namespaceOverride: jupyterhub-prod

Or via Helm CLI:

helm install my-release ./jupyterhub \
  --namespace release-ns \
  --set namespaceOverride=custom-ns

Testing

• ✅ Verified all 45 namespaced resources have explicit namespace field
• ✅ Verified all 5 cluster-scoped resources correctly have NO namespace field
• ✅ Verified all RoleBinding subjects have namespace field
• ✅ Verified all lookup functions use namespace helper
• ✅ Cross-referenced against authoritative Kubernetes resource list

Files Modified

59 files total:

• 3 configuration/helper files
• 10 hub resources
• 12 proxy resources (including autohttps)
• 9 scheduling resources
• 7 image-puller resources
• 2 singleuser resources
• 3 top-level resources
• 1 documentation file

See full verification report in commit messages.

[manics]

Can you please explain why this is needed? I've deployed Z2JH using ArgoCD without namespace problems.

[ethanchowell]

We've hit this a handful of times with various deployments and I think this note from the ArgoCD team summarizes it. In our cases argocd is managing apps for multiple clusters and the application namespace is not the destination namespace of jupyterhub. Handling this at the chart level allows us to get around this limitation

[duncan-i3-work]

Anything need to be done here?