zyratlo opened a new issue, #7390: URL: https://github.com/apache/texera/issues/7390
### Feature Summary `notebook-migration-service` is currently built for a per-user-pod deployment: each user would run their own pod containing both JupyterLab and a co-located `notebook-migration-service` JVM. Because of that assumption, the service holds process-global state for the "current" Jupyter iframe and reads a single static Jupyter URL and token from configuration. It has no notion of which user a request belongs to. Every other Texera microservice follows the opposite pattern. `access-control-service`, `file-service`, `config-service`, `workflow-compiling-service`, `computing-unit-managing-service`, and `agent-service` are all deployed as single global instances. Only the stateful resources (compute pods, Jupyter) are per user. The consistent principle is: orchestrator services are global, stateful resources are per user. `computing-unit-managing-service` is the closest analog. It is a global service that resolves each user's compute pod and routes requests to it. `notebook-migration-service` plays the same orchestrator role for Jupyter pods, so it should be brought into the same shape. Keeping `notebook-migration-service` per user has two costs: 1. The process-global iframe state is only safe because the pod boundary happens to isolate users. A single shared instance would let one user's activity affect another's, and even within one user it allows a multi-tab race. 2. The per-user-pod choice is out of step with the rest of the platform and risks being inherited by accident in later work if it is not addressed deliberately. ### Proposed Solution or Design The work is staged so no single PR is too large and so the tool stays fully functional at every step. - Make the API stateless. Remove the process-global iframe state so results are computed per request. This is backward compatible, removes the multi-tab race on its own, and does not depend on any deployment change. - Resolve each user's Jupyter pod dynamically, using the same Kubernetes DNS pattern as `computing-unit-managing-service`, with a fallback to the existing static configuration so local development and current deployments keep working. - Move the deployment topology: run `notebook-migration-service` as a single global deployment, spawn addressable per-user Jupyter pods, and add a network policy to prevent cross-user Jupyter access. - Update the frontend to coordinate per-workflow notebook naming so a global service can distinguish users and workflows. ### Affected Area Other -- 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]
