zyratlo opened a new issue, #8006: URL: https://github.com/apache/texera/issues/8006
### Feature Summary The notebook migration tool now runs in the single-node Docker Compose stack (#7931) and in the local development tooling (#7933), but it is absent from the Helm chart. `bin/k8s/templates/base/` has no `notebook-migration-service` directory and no JupyterLab service, and `values.yaml` has no setting for either. A Kubernetes deployment of Texera therefore shows the tool in the workspace UI with no backend serving its endpoints and no notebook server to embed, which is the same gap single-node had before #7932. This is stage 3 of the staged roadmap in the architectural note on #5258. Stage 1 (#7390) and stage 4 (#7671) are merged; stage 2 (#7665) resolves the Jupyter endpoint and credential per user and must land first, because the topology below depends on it. ### Proposed Solution or Design Add the service to the Helm chart following Texera's existing convention: orchestrator services are global, stateful resources are per user. * `notebook-migration-service` runs as a single global Deployment, alongside `config-service`, `file-service`, `access-control-service`, and `workflow-compiling-service`, with its API routed through the existing gateway like every other service. * JupyterLab runs per user, as an addressable pod the service resolves at request time. `workflow-computing-unit-pool` is the closest existing model for per-user workloads and its namespace, service, and resource-quota templates are the reference to follow. * A NetworkPolicy prevents one user's traffic from reaching another user's JupyterLab pod. The chart has no NetworkPolicy today, so this establishes the pattern rather than extending one. The browser loads JupyterLab directly for the workspace iframe, so the address handed to the browser is not the address the service uses to reach Jupyter inside the cluster. #7932 already split these into `storage.jupyter.internal-url` and `storage.jupyter.public-url`; the chart has to set both correctly for a per-user pod. An operator should be able to enable or disable the tool from `values.yaml`, matching how the feature flag works in the other deployments. Scope and limitations: * Depends on #7665. Without per-user resolution, a global service instance would hand every user the same Jupyter and the same token, which is exactly what the global topology is meant to prevent. * Pod lifecycle (on demand versus always on) is settled as part of #7665 and inherited here. * The single-node and local-dev deployments continue to run one shared JupyterLab from static configuration. That stays acceptable on a single operator-controlled machine and must not be carried into this deployment. ### 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]
