Skip to content

[Notebook Migration] Manage the notebook migration service and JupyterLab in the local dev tooling #7933

Description

@zyratlo

Task Summary

bin/local-dev.sh is the entry point for running Texera on a contributor's machine: it starts the supporting infrastructure in Docker and runs the JVM and Node services natively. It does not know about the notebook migration tool. Neither notebook-migration-service nor the JupyterLab server the workspace embeds is in its service catalog, so a contributor running the local dev stack has the tool visible in the GUI but no backend serving its endpoints and no notebook server to embed. Reproducing or working on the feature currently means starting those pieces by hand alongside the managed stack.

Register both with the local dev tooling so they start, stop, and report state like every other managed service, and appear in the dashboard alongside the rest.

Two smaller items belong with this work:

  • The JupyterLab server is the only managed service that runs from a Texera built image rather than natively. Editing its customizations therefore has no effect until the image is rebuilt, which is not obvious and is not written down anywhere. The local dev documentation should explain it.
  • The startup summary reports a hardcoded container count that is already one short once JupyterLab is registered.

This depends on the single-node deployment work, which is where the JupyterLab service and its image are defined.

Task Type

  • Refactor / Cleanup
  • DevOps / Deployment / CI
  • Testing / QA
  • Documentation
  • Performance
  • Other

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions