Choose timezone
Your profile timezone:
GSoC 2017 - Big Data Tools for Physics Analysis
→
Europe/Zurich
31/S-028 (CERN)
Attendees: Krishnan, Danilo, Prasanth
Actions:
o Check how to properly implement the "Cancel" jobs button without needing to restart the kernel after interrupting the cell
o Identify and prototype an aggregated view for the running tasks: the current visualisation will be kept as it is very detailed and may be needed for debug. On the other hand it does not scale to ~100 workers. The aggregation can be a timeline of the number of tasks.
o Implement some sort of pop up when hovering on the task bar displaying some information relative to it
o Identify a solution for the problem relative to more than one notebook using the same linux socket via py4j to interact with the jvm. Ideally the user should not be exposed to any detail relative to this.
o Setup a demo server for the mentors to see the changes in the JS display.
Cancel jobs button:
- Does not work always. It hangs sometimes. The kernel takes code from the cell and executes it: this channel is used to transmit the cancel button too. The cell has to be stopped, the channel is then freed. The problem is that the kernel gets into a funny state and needs restarting.
Look and feel:
- vis.js time module used for the timeline. We'd like to see if some units can be added and "0" "000" can be displayed when zooming.
- We'll have some pop up when hoovering over the tasks.
- Prasanth proposes to project the number of tasks into a single number. We agree that the individual tasks are great and we need them. One useful thing would be have an aggregated view with the time series of the number of active tasks.
Known bugs (besides the ones on github):
- If the kernel is not ready, the communication should not be started by the user
- Py4j allows only one connection and this is a problem with multiple notebooks.
- Hook up with the scala listener: no obvious way with py4j. Today it is not possible to hide the necessary steps into the configuration. We'd need a way to hide all of this from the user, perhaps defining in the kernel an env variable with the right port.
Access to CERN resources:
- Krishnan will be given a CERN account so that he can setup a demo server for all the mentors to access.
- Krishnan will try first to install and use his extension from SWAN. If this is not possible due to e.g. conflicts with the Jupyter version, Krishnan will extend the Docker image of SWAN (SLC6) to include his Jupyter extension; after that, he will spawn his customized container in a VM at CERN so that mentors can access a Jupyter server with the extension in it.
There are minutes attached to this event.
Show them.