Feature Summary
notebook-migration-service reads a single Jupyter URL and token from configuration (StorageConfig.jupyterURL / jupyterToken), held as process-wide values. This is safe only under the per-user-pod model, where each user runs their own pod with its own Jupyter. It blocks running the service as a single global instance: a shared instance would hand every user the same Jupyter and the same token.
The stateless refactor (#7390) removed the process-global iframe state, which was one half of the per-user coupling. This issue tracks the other half: resolving the Jupyter endpoint and credential per user instead of from one static config value.
Proposed Solution or Design
Resolve each user's Jupyter pod dynamically rather than from a single static URL and token, following the same pattern computing-unit-managing-service already uses to reach per-user compute pods (Kubernetes DNS resolution). Concretely:
- Introduce per-user resolution helpers (for example
jupyterUrlFor(uid) and jupyterTokenFor(uid)) that map a user to their Jupyter pod.
- Fall back to the existing static configuration when no per-user pod is present, so local development and current deployments keep working unchanged.
- Spawn addressable per-user Jupyter pods so the resolver has something to resolve to.
This is stage 2 of the larger effort to bring notebook-migration-service onto Texera's "orchestrator services are global, stateful resources are per user" pattern. See the forward-looking architectural note on #5258 for the full staged roadmap. Later stages cover the global deployment topology (a single global service with a cross-user network policy) and frontend coordination.
Open questions to settle when this is picked up:
- Per-pod Jupyter tokens (more secure) versus a shared token (simpler).
- On-demand versus always-on Jupyter pod lifecycle.
Affected Area
Deployment / Infrastructure
Feature Summary
notebook-migration-servicereads a single Jupyter URL and token from configuration (StorageConfig.jupyterURL/jupyterToken), held as process-wide values. This is safe only under the per-user-pod model, where each user runs their own pod with its own Jupyter. It blocks running the service as a single global instance: a shared instance would hand every user the same Jupyter and the same token.The stateless refactor (#7390) removed the process-global iframe state, which was one half of the per-user coupling. This issue tracks the other half: resolving the Jupyter endpoint and credential per user instead of from one static config value.
Proposed Solution or Design
Resolve each user's Jupyter pod dynamically rather than from a single static URL and token, following the same pattern
computing-unit-managing-servicealready uses to reach per-user compute pods (Kubernetes DNS resolution). Concretely:jupyterUrlFor(uid)andjupyterTokenFor(uid)) that map a user to their Jupyter pod.This is stage 2 of the larger effort to bring
notebook-migration-serviceonto Texera's "orchestrator services are global, stateful resources are per user" pattern. See the forward-looking architectural note on #5258 for the full staged roadmap. Later stages cover the global deployment topology (a single global service with a cross-user network policy) and frontend coordination.Open questions to settle when this is picked up:
Affected Area
Deployment / Infrastructure