Overview
(this will be focusing on the CDDR project, but will eventually become a landing page for the Workbench)
As part of this CDDR we would like to take the existing Workbench software and extend it by adding an administrative interface that will allow administrators of the Workbench to curate the visible list of software for each user, as well assign resource limitations to the user. It will also be necessary to upgrade the frontend framework used to create Workbench, as even the “popular” Javascript libraries seem to rotate or mutate every few years. Specifically, we will add the following functionality:
User management:
Integration with other authentication methods, such as CILogon
Based on their roles users will have different sets of applications available.
Based on their roles users will have different resources limits
Add NCSA software to Workbench
Easily allow admin to browse catalog of software and enable this software
Upgrade to a newer version of Angular since the current version is only supported until early next year.
Upgrade to a newer version of helm making it easier for others to deploy
Desired Features
Role-Based Access Control
Currently, we have no notion of "admin users". There is a single admin whose main functionality is only accessible via command-line - this feels very dated.
It would be nice to be able to tag a user with one or more roles (e.g. Admin) to grant access to more advanced functionality in the UI.
Another huge advantage of this is that we can tune the complexity of the UI to the user's needs.
For example, non-admin users may be overwhelmed by the Add/Edit Spec page or how to use Import Spec, and may opt not to use it at all. For these users, complex functions can be hidden from the UI, leaving them to focus only on those parts that help them complete their work.
The final advantage here is that non-admin users can have more restrictive resource limits, while admin users may have slightly higher resource limits to accomodate more advanced functionality.
Roles (TBD)
- User => no special permissions, can read and launch applications from the catalog and read their config
- Developer => in addition to the above, can edit applications and access application logs and console
- Editor => in addition to above, can create, import, edit, and clone specs to their own personal catalog
- Publisher => in addition to above, can create and import specs to the system catalog
- Admin => in addition to the above, can use any API endpoints (e.g. delete specs from system catalog, RBAC/user management, etc)
Add NCSA Software to Workbench
Gather any potential software candidates below:
- Clowder (present, may still work but needs updates)
- Datawolf (present, may still work but needs updates)
- Geodashboard
- Others?
OAuth Login
Workbench once supported login via GitHub using bitly's ouath2_proxy. I think Craig added some support for Globus Auth as well.
We may be able to leverage this integration or produce something similar to use something like CILogon, if desired.
In any case, the OAuth login process will require significant credits.
Using the Workbench to launch Clowder
The Workbench offers a set of application specs for Clowder + MongoDB + RabbitMQ + Elasticsearch + a few core extractors + PlantCV extractor. (see the ndslabs-specs repo)
We may need to upgrade the spec to use the latest image and retest to verify that it still works.
Using Clowder to launch tools alongside data on the Workbench
Clowder has a lightweight plugin called the ToolManager that allows users to launch tool containers (e.g. Jupyter, RStudio, etc) with data from Clowder mounted in.
We would like to expand Clowder to integrate with the Workbench to handle this for us, and retire the previous ToolManager.
Some considerations:
- How do we authenticate into Workbench from Clowder? Workbench → Clowder uses cookies/headers to cache auth.. maybe Clowder → Workbench can read Clowder's cookie and check its validity?
- How will the data get into the container? Download after startup (as before)? Mount same directory from Clowder into Workbench container (assumes DiskByteStorage)?
Source Code References
Workbench API + UI source code: https://github.com/nds-org/ndslabs
Kubernetes Deployment
Kubernetes single-node deployment: https://github.com/nds-org/kubeadm-bootstrap
Kubernetes multi-node deployment: https://github.com/nds-org/kubeadm-terraform
Application Catalogs
Main spec catalog: https://github.com/nds-org/ndslabs-specs
CHEESEhub spec catalog: https://github.com/cheese-hub/catalog
TERRAREF spec catalog: https://github.com/nds-org/ndslabs-specs/tree/terra-ref
Applications from Workshops / Courseware
Earthcube spec catalog: https://github.com/nds-org/ndslabs-specs/tree/earthcube
GlobusWorld spec catalog: https://github.com/nds-org/ndslabs-specs/tree/globus/globus
PI4 Bootcamp spec catalog: https://github.com/nds-org/ndslabs-specs/tree/pi4
Zeppelin + Spark spec catalog: https://github.com/nds-org/ndslabs-specs/tree/spark
ThinkChicago spec catalog: https://github.com/nds-org/ndslabs-specs/tree/thinkchicago