The following major features are under consideration for ongoing Workbench development:
Priority | Feature | Description | Priority |
---|---|---|---|
Authentication and authorization | |||
Add support for integration with external authentication and authorization systems.This includes adding OAuth/OIDC support; integration with CILogon /COManage and Globus Auth. | 1 | ||
Support authorization models to enable access to data and other resources (COManage, LDAP). Consider looking again at KeyCloak/LDAP, particularly with eduPerson support. | 1 | ||
Workbench/Cloud | |||
Simplified installation | 2 | ||
Ability to export services to run in VM or container-based environments. | 3 | ||
Ability to install Workbench in commercial cloud environments with storage support .Simplified installation in OpenStack environments.(NFS v Gluster) | 1 | ||
Integration with other orchestration environments (e.g., Swarm). | Ability to export services to run in VM or container-based environments.3 | ||
Workbench/HPC | |||
Ability to run analysis developed in Workbench via HPC using standard APIs (Airavata, Agave). | 1 | ||
Convert Docker containers to Singularity. | 1 | ||
Login node replacement (i.e., use workbench as parallel resource to HPC system to support development, interactive analysis and visualization. | 3 | ||
Workbench/Gateway | Ability to develop applications in Workbench and deploy/publish for wider access (same as export to cloud above) (TERRA-REF "Shiny" use case), GCMC; Ability to develop and deploy data portals. | 3 | |
Container preservation | Zenodo for Dockerhub/Singularity. Provide a centralized and distributed registry/cache specific to scientific/research oriented software that includes DOIs. This came up as a case at CAE Workshop and is not solved by WT. | 3 | |
Education and training | Ability to easily "spin up" instances near data for workshops and training; models for creating temporary training accounts; integration with external systems (e.g., map reduce, etc). CaseaCase: PI4, Einstein Toolkit. | 1 | |
Private/public data | Support for mounting and publishing data in a variety of formats. Cases: NBI raw/Mongo DB, TERRA BETYdb, ThinkChicago data. Requires permissions model; | 3 | |
NBI prototype | 1 | ||
Batch/Workflow support | Ability to integrate with batch and workflow systems; both via containers and outside. Casea: LIGO, BrAPI, CyVerse, KnowEng | 3 | |
Custom catalog/branding | 3 | ||
Backup, recovery, failover, monitoring | Improve backup/recovery, failover and monitoring support. | 2 | |
Configurable resource limits | Ability to request more resources for interactive sessions from container-based environment (ala JupyterHub "profiles") | 2 | |
Integration with Data Portals | Clowder, HubZero, DataVerse, Girder – ability to fulfill DataDNS vision. | 3 | |
JupyterHub interoperability | 3 | ||
For-fee service | Process for requesting workbench instance for some duration with associated fees. Similar to system used by events group. | 3 | |
Administration console | Admin web interface for common functions (ndslabsctl) | 3 | |
Usage reporting | 2 | ||
Einstein Toolkit Tutorial instance | 1 | ||
Filesystem performance testing | Openstack + Docker + Gluster: find the absolute best configuration for performance. | Go away | |
Documentation updates | 1 | ||
Twitter use case | 1 | ||
Stitching use case | 1 | ||
ETK use case | 1 |