# 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.