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

  • No labels