mapsacosta / eafjupyter Goto Github PK

There doesn't seem to be an easy way to cancel a file upload. There is a status bar that says "Uploading" but no way to cancel it. For example, when trying to cancel the upload of a ~800 MB file, I can not cancel the upload. "Delete" and restarting the kernel both don't seem to cancel the upload.

Changing the Theme and setting other configs from the UI require permissions to write/modify config files. There is currently a permission denied error happening on the Development instance that needs fixing:

notebook [W 2021-11-15 21:12:20.861 **** web:1787] 500 PUT /user/****/lab/api/settings/@jupyterlab/apputils-extension:themes?1637010740418 (::ffff:10.102.0.1): Failed writing settings (@jupyterlab/apputils-extension:themes): [Errno 13] Permission denied: '/etc/jupyter/jupyter_notebook_config.py:'

Upon logging in, users are presented with a variety of computing options. Users can choose one, and then click "Start my Server." However, users don't know whether one is available or not until after clicking. The landing page should indicate whether or not a GPU resource is available or not, since after clicking "Start My Server," the page will hang with "Your server is starting up" even though there are no GPUs available (0/14 nodes are available).

Several images missing, sounds like an easy fix.

Currently, can not delete folder in home directory by right clicking and choosing 'Delete' from the gui. Currently, would need to delete all files in the folder, and then the folder from gui.

Minor QoL improvement request! Would it be possible to enable "view hidden contents" in the Jupyterlab config so we can see hidden files and folders in the directory browser? its currently possible to access them through the terminal just fine, but there are some cases where it'd be nice to see it graphically too. From what I can tell it just involves setting a flag to true in jupyter_server_config, as described here:
jupyterlab/jupyterlab#11304
jupyter/notebook#3812
https://jupyter-notebook.readthedocs.io/en/stable/config.html#options (ctrl+f ContentsManager.allow_hidden)

I think that adding the following line to the base notebook's jupyter_notebook_config.py would probably work?

c.ContentsManager.allow_hidden = True

This issue is created in order to address beta testers' feedback for the analytics-hub.

Please make sure to include:

• The "Flavor" of the notebook/environment you launched,
• What you expected to happen?
• What actually happened?
• Any extra features you'd like to see in the future?

We are hoping to test some of the following features at this stage:

LPC notebooks:

• CVMFS mounts
• NFS LPC home area + scratch + d1,2,3
• EOS aliases, xrootd/xrdcp, gfal tools
• X509, auth tools: Getting a voms proxy, getting a krb ticket (klist, kinit)
• Basic CMS development environment functionality: cmssw, python, root, scram
• Jupyter functionality: Web terminal, ipython notebook general fuctionality, start/stop notebook pods, install/use ipywidgets

COFFEA-CASA/DASK notebooks:

For tutorials and information on getting started with dask-gateway, see documentation here

• Connecting and authenticating with the dask-gateway API server
• Listing active dask clusters
• Launching kube dask clusters, scaling (manual or "adaptive")
• Connecting to existing clusters, running basic analysis, shutting down clusters properly.
• Dask dashboard proper display and proxying

DUNE notebooks:

• CVMFS mounts
• xrootd/xrdcp, gfal tools
• X509, auth tools: Getting a voms proxy, getting a krb ticket (klist, kinit)
• Basic DUNE development environment functionality: larsoft, python, root
• Jupyter functionality: Web terminal, ipython notebook general fuctionality, start/stop notebook pods, install/use ipywidgets

AD notebooks:

• Auth tools: getting a krb ticket (klist, kinit)
• Basic READS development environment functionality
• Shared persistent storage permissions
• Jupyter functionality: Web terminal, ipython notebook general fuctionality, start/stop notebook pods, install/use ipywidgets

I know it's possible to source CVMFS from the Terminal environments inside the JupyterLab, just do it the usual way, i.e. source /cvmfs~/setup_dune.sh. The whole thing behave just like any other virtual machine terminal.

However, dynamically adding CVMFS products inside a notebook environment is much harder, i.e.

1. Setting os.environ["PATH"] or os.environ["LD_LIBRARY_PATH"] won't affect the path look up in the current kernel
2. %env magic function won't work
3. I could predefine the CVMFS paths into kernel.json, but that won't dynamically change the environment.
4. For example, if I started the Jupyterlab without a CVMFS version of ROOT, I can't setup the environment from within the Jupyter notebook to use it later. ( so no import ROOT in the interactive environment)
5. I also couldn't change the ROOT version in the notebook.

I understand that once a single-user JupyterLab server is launched, the default system environment is basically fixed in place.
However, there seems to be a way to setup a product before launching a notebook inside the server:

see https://github.com/cmd-ntrf/jupyter-lmod

Since (if I'm correct) all the product-sourcing business really boils down to getting the paths into the kernel, it might be possible to either inject the paths on the fly or dynamically create a kernel before notebook launch?

Or is there an easier way?

When uploading large files via the gui, the default message for large files seems to be "The file size is 677 MB. Do you still want to upload it?" even if the file size is not 677 MB.

Facility ADMINS read carefully:

Please revisit the following package versions changed recently at repository "$GITHUB_REPOSITORY" by "$GITHUB_ACTOR" registered as 'Fermilab-EAF'
This means that the synchronized file for version locks was modified by a :

Commit information:

commit 6b40b192f27beeb142418b53a9e31ef290fe1b97
Author: macosta <[email protected]>
Date:   Thu Sep 9 20:54:17 2021 -0500

    Removing redundant pre-issue step

This will trigger builds in a lot of places, so make sure the new pinned version locks are accurate:
DASK_VERSION=2021.8.1
DASK_GATEWAY_VERSION=0.9.0
DISTRIBUTED_VERSION=2021.8.1
CLOUDPICKLE_VERSION=1.6.0
COFFEA_BASE_IMAGE=coffeateam/coffea-base-cc7:0.7.7-fastjet-3.3.4.0rc9
COFFEA_VERSION=0.7.7
UPROOT_VERSION=4.0.8
XROOTD_VERSION=5.2.0

Hello,

First of all congratulations for this very nice system. I have a question which maybe doesn't belong here, so feel free to close the issue and redirect me to the appropriate place. I was wondering what was the most appropriate way to share a Jupyter kernel among collaborators. Is there a shared directory accessible by every user? Or the best option is to save the conda environment on cvmfs? How are other experiments solving this problem? I am a member of the Mu2e collaboration.

Thanks!