Related issue: NDS-740 - Getting issue details... STATUS
Notes from the Phenome 2017 TERRA-REF workshop.
Background
We setup a dedicated instance of Labs Workbench for the TERRA-REF workshop at Phenome 2017. The instance was create in the NDS-hackathon project and scaled to support ~30 simultaneous users launching custom Jupyter and RStudio environments to analyze data from the TERRA-REF reference dataset.
Registration confusion
There was confusion about which system to use for registration. The project manager accidentally used the primary NDS instance, which was slated for maintenance. As a result, users were inadvertently spammed with email from the system. This was primarily a communication problem, suggesting better coordination with the workshop team to understand the process.
Account registration
While the project manager registered users manually, it was possible (and in the end we did) to import the user accounts directly, bypassing email verification and approval. The approval workflow was disabled for this instance anyway. Additionally, the support email should be the PI or PM, not ndslabs-support.
Branding and documentation
The dedicated instance has NDS-specific welcome page and documentation that assumes our primary use case (sandbox for playing with lots of services). It might be worth considering a customizable landing page that can link to instance-specific documentation.
Custom catalog and images
Supporting the workshop required the creation of a custom catalog (https://github.com/nds-org/phenome2017-specs) and Docker images. This required our help, since the workshop organizers didn't have the ability to do either.
Shared data
Home directory confusion
The distinction between container effective user home directory "~" and /home/namespace was hard for the PI. Additionally, the containers didn't have dedicated volumes, so user changes were lost across container restarts.
Scaling up/down
Initial setup can be small – just PI testing – then scale up for workshop day and scale back for post-workshop period
Availability
Requirements weren't clear, but the PI wanted the system to be available for the duration of the conference and for the users to be notified before their containers were shutdown, with the ability to export either the container.
Auditing/usage analysis
How many users did what for how long, how many and which containers did they launch? What resources did they use?
TLS
We disabled TLS since the workshop was only for a day, but should confirm with NCSA security whether this is the best approach.