zyratlo opened a new issue, #7665: URL: https://github.com/apache/texera/issues/7665
### 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 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
