# Spyder's Remote development Develop the spyder-remote-server, responsible for managing jupyter's kernel, spyder's kernel and integrating any python's package to be run remotely and allowing for remote operations with Spyder's client. # 31/01/25 * Ignore hosts in asyncssh options * Check if that works with Putty on Windows # 27/01/25 # 06/12/24 * Write proof of concept in the server for the remote file system support using the Jupyter server API * Concluded that it'd be too much work to use that approach * Moved to implement the ftp server instead * Finishing to implement the client side on Spyder (should finish by Monday) # 29/11/24 * Merged PR for server refactoring and client-side changes # 22/11/24 * Hendrick was ill so he couldn't make any progress # 15/11/24 * Hendrick's updates * Almost done with server refactoring * Hendrick's action items * Push PR with the refactoring * PR with Spyder client changes # 08/11/24 * Hendrick's updates * Add test for server version in Spyder * PR with versioning check * Hendrick's action items * Push PR with the refactoring * PR with Spyder client changes # 01/11/24 * Hendrick's updates * Almost done with the server refactoring * Work on the necessary changes on the Spyder * Hendrick's action items * PR with versioning check * PR with Spyder client changes * Push PR with the refactoring # 18/10/24 * Hendrick's updates * PR to add subrepo for remote-services * PR to fix bug when connecting to remote existing kernels * Hendrick's action items * Push refactor for the server # 07/10/24 * Hendrick's updates * Use docker for tests or start/stop the server for the server tests? * Address review for client tests PR * Hendrick's action items * Push PR with tests for the server * Push refactor for the server * Connecting to JupyterHub # 04/10/24 * Hendrick's action items * Address review for client tests PR * Push PR with tests for the server * Start refactoring for the server # 23/09/24 * Hendrick's action items * Finish the tests PR * Open PR to transform remote-services to become Jupyter server extension. * Open PR on Spyder to connect to extensions. # 20/09/24 * Hendrick's action items * Continue working on the tests PR # 10/09/24 * Hendrick's action items * Submit PR with tests * Start to add env management capabilites * Carlos action items * Check package info in envs-managers # 02/09/24 * Hendrick's action items * PR with tests * Add env management capabilites * Carlos action items * Check package info in envs-managers # 17/04/24 * Carlos action items * Improve UI for starting/closing consoles. * Check restart/interrupt kernels. * Move my changes to backend PR. * Hendrick action items * Run Black on the backend code. * Finish tests * Do code refactoring * Create a separate env for Spyder-kernels in the server. # 10/04/24 * Carlos action items * Put the ConnectionStatus enum in `api/protocol.py` * Finish UI to connect to servers and start remote consoles * Hendrick action item * Finish status handling in `SpyderRemoteClient`. * Do refactoring and code formatting. * Start to integrate tests. ## 03/04/24 * Feedback from Carlos * I was able to start a server from the UI. Yay!! * But it required a bit of hacking (manually setting the port of spyder-remote-server) and I found several issues (listed below). * Connecting to a server blocks the UI. * To fix it I think we need to use `qt-async-threads`. * I did a very crude proof of concept to test it and managed to start a connection with `qt-async-threads` without blocking the UI. So it looks promising. * Reading the spyder-remote-server port from stdout in `SpyderRemoteClient.__extract_server_port` is brittle. * In my case it breaks due to a libmamba warning, so the port can't be read from the stream. * Perhaps it'd be better to make the server write the port to a file in disk and read it from it. * `SpyderRemoteClient` doesn't exactly report the connection status but I need that so I can show it in the UI. * In `client.connect_and_ensure_server()`: * `True`: Connection succesful, right? * `False`: Error? But what kind of error? * How should we handle this? * The API at the plugin level can be cleaned up a bit: * `start_remote_server` could simply call `connect_and_ensure_server`. * `ensure_remote_server`, `install_remote_server`, `restart_remote_server` could be removed. * `load_*` methods can be made private. * I need clarification about the following entries in `SSHClientOptions`: * `client_keys`: SSH keyfile * `known_hosts`: Setting to `None` to accept any host. * `config`: SSH config file * `password` also works for the key file passpharse? * Hendrick will add passhprase to `SSHClientOptions`. ## 27/03/24 * Hendrick action items * Finish managing multiple connections with threads. * Start working on the server and client tests and check how to run them in sync. * Carlos actions items * Start integration of the frontend with the backend. * Connect to logging info that comes from the remote machine * Add regex to chek remote addresses * Show last log message as a QMessageBox if there's an error connecting to the rmeote machine. ## 06/03/24 * Hendrick action items * Start a new kernel and ensure that a server is installed once (per client config). * Max number of server to different hosts of 5 (send signals if max reached). * Move server log to a sync stream to be accesible by the plugin. * Check if the server is installed when starting the server (start_server_ensure_installed). * Submit the refactored code. * Carlos action items * Keep working on the UI and make it start a server for next time. ## 28/02/24 * Hendrick action items * Check client is working inside Spyder * Start work on the tests. By next meeting have them running * Carlos action items * Check docker image: `docker compose up`: * IP: 172.16.128.2, port:22 * User/password: ubuntu/ubuntu * ubunbu@172.16.128.2 * Create PR with preparation UI fixes and ask Hendrick to rebase after that PR is merged. * Have prototype UI for next meeting. ## 31/01/24 * Hendrick action items * Upload server code and publish a dev version of it (`a0` or `b0`). * Finish Spyder client and create PR in Spyder repo. * Once that's done, take a look at how to interrupt kernels with our Comms protocol. * Carlos action items * Start implementing dialog to receive and save SSH credentials ## 24/01/24 * Hendrick action items * Upload server code and publish a dev version of it (`a0` or `b0`). * Finish Spyder client and create PR in Spyder repo. * Once that's done, take a look at how to interrupt kernels with our Comms protocol. * Carlos action items * Create dialog to receive and save SSH credentials from users. - **WIP** * Share the UI mockups for that dialog and the menu to start consoles in remote servers. - **Done** * Send invite to our Google drive - **Done** ## 20/01/24 * Hendrick action items * Check things in WSL - **Done** * Start developing Spyder client - **WIP** * Create script to download Micromamba and setup the server environment - **Done** * Carlos action items * Refactoring preferences config dialog to create more dialogs like it - **WIP, only tests are missing** ## 10/01/24 * Integrate Spyder-kernels with test file. * Start client on the Spyder side and connect it to the server. ## 03/01/24 * Carlos action items * Create spyder-remote-server repo * Hendrick action items * Finish UML diagrams * Create a prototype * Check how to extend Jupyter-client ## 20/12/2023 - Develop a separated project responsible for remote comunitations; - Implement [sshfs](https://github.com/fsspec/sshfs) as an API for remote file management; - Study whether we will use [jupyter-enterprise-gateway](https://github.com/jupyter-server/enterprise_gateway) or a custom kernel manager; - Use [asyncssh](https://github.com/ronf/asyncssh) as the python's api for ssh client/server - Propose an model for the *spyder-remote-server* project.