zyratlo opened a new issue, #7931: URL: https://github.com/apache/texera/issues/7931
### Feature Summary The notebook migration tool converts a Jupyter notebook into a Texera workflow. The backend microservice and the workspace UI have both landed (#5258 and the follow-up frontend work under #4301), but neither is part of any deployment. A user who runs Texera through the single-node Docker Compose stack cannot use the feature at all: nothing starts the service that serves its endpoints, and there is no JupyterLab server for the workspace to embed. Today the tool only works if a developer starts the pieces by hand. ### Proposed Solution or Design Run the notebook migration service and a JupyterLab server as part of the single-node stack, and route the tool's API traffic through the existing reverse proxy so the frontend reaches it on the same origin as every other service. Two behaviors this needs to get right: 1. The browser loads the JupyterLab server directly, because the workspace embeds it in an iframe. The address handed to the browser is therefore not the address the backend itself uses to reach Jupyter inside the deployment network. Both need to be correct at the same time. 2. The conversion is powered by an LLM, so it depends on the same API key configuration the Texera agent already uses. With no key configured, the tool should still appear and fail with a clear provider error, matching how the agent behaves today. An operator should be able to turn the feature off from deployment configuration, and the port exposed for JupyterLab should be configurable like the other published ports. The deployment documentation should cover the new port, how to enable or disable the tool, and the security note below. Scope and limitations: * This covers the single-node Docker Compose deployment only. Kubernetes deployment is out of scope. * Support in the local development tooling is a separate follow-up, since it depends on this work landing first. * Every user of a single-node deployment shares one JupyterLab server and one access token, so anyone who can reach the deployment sees the same notebooks. That is acceptable on a single machine the operator controls, and it must not be carried into a multi-user 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]
