Build control flow to add, edit and run code

[achadha0111]

This is a brain dump for what the ideal code execution environment would look like and what features of the kernel need to be supported on the front end.

[achadha0111]

My very birds eye view of the problem components is:

1. Our website serves as the front end.
2. On login, the user is authenticated with a single user kernel server running behind Jupyter Hub (this is carried out using the Jupyter Hub REST API). Successful authentication returns an API endpoint against which we can send queries. The JupyterHub REST API can be accessed here.
3. This API endpoint can then be queried using the JupyterLab services which essentially takes an endpoint and exposes methods against the endpoint:
4. The top level concepts involved in the service module are:
   • Clients: An entity connected to the kernel, in our case, this is the notebook.
   • Kernelspecs: A kernel spec is the data record about available kernels on the system. This is usually retrievable from the server.
   • Kernel: The running process on the server that implements the Jupyter messaging protocol.
   • Kernel model: A kernel model (as of my current understanding from reading the docs) is the client side state of the server kernel model. The model can be created, restarted, shut down (need to find the complete list!). This is disposed off when the server kernel is shut down.
   • Kernel Connection: A single client connection to the kernel over a web socket. This too has a number of signals such as status, connection status and these need to be found out.
   • Kernel Manager: Bookkeeper and connection manager for kernels, interaction of server kernels is handled through this.
   • Sessions: A context manager with features such as model, connection and manager to help persist connections to a kernel. It exists during the lifecycle of a client.

[achadha0111]

The states that must be displayed in our notebook are:

1. Code is executing.
2. Code execution has finished (with/without results).
3. Execution count.
4. Code has thrown error (with traceback).
5. Kernel is starting.
6. Kernel is ready.
7. Kernel is running.
8. Kernel is shutdown.

The user should have access to the following actions:

1. Execute code.
2. Restart kernel.
3. Stop kernel.

[achadha0111]

Task 1 is getting a test JupyterHub deployment running with full access to test out the service API.

To do this, I have to follow this:

1. AWS Elastic Kubernetes Service