This document is out of date and should be removed after confirming that all use cases are represented in JIRA
------
This is a preliminary set of use cases for the NDS Labs systems.
What is NDS Labs?
NDS Labs is an experimental development platform for hosting NDS pilot projects that emerged out of the NDS2 and NDS3 consortium workshops. NDS Labs is intended to provide consortium developers access to significant storage, virtual machines for hosting, and a variety of existing, commonly used data tools (e.g., databases, iRODS, Globus services, etc). NDS Labs enables developers to try out new ideas for tools, services, and standards. Developers working in labs have the ability to create a virtual cluster of machines and launch applications within each node. Developers are encouraged to package new applications and, if appropriate, share them with other projects within Labs. NDS Labs should provide high-level architecture documentation, summaries of key technologies used, and examples of use. NDS Labs should support different scenarios based around the different types of projects we expect to support.
Users/Actors:
- Site administrator: Infrastructure and cluster administration at NCSA, TACC, SDSC.
- NDS cluster administrator: Internal administrator that provisions approved projects and assigns quotas
- NDS project admin: External user of NDS Labs services. Access the GUI/CLI to manage services within a project.
- End user: External user of services deployed via NDS Labs (e.g., Dataverse, Clowder)
- NDS developers: Local development staff and community members
NDS Operations
Prerequisites:
- Openstack
Use cases:
- Site administrator creates tenant with sufficient resources (compute/storage) for NDS Labs cluster.
- Site administrator can start a Kubernetes cluster (NDS-98). They are prompted to specify the cluster size. The deployer provisions VMs, deploys pre-defined OS images, starts Kubernetes base services.
- Site administrator starts admin services (NDS-92). These are centralized logging/monitoring services used by NDS Operations across all sites.
- Site administrator starts NDSLabs services (e.g., API server, GUI service, etc). (TBD)
- Site administrator can stop the cluster (TBD). (We need to define what this looks like – are resources reclaimed? or are services simply shutdown gracefully?)
NDS Site Admin
Prerequisites:
- Base Kubernetes cluster and NDSLabs services are running
Use cases:
- NDS cluster administrator manages services library (TBD). Tentatively, admin must be able to add, modify, and remove NDS Labs services available to project administrators.
- NDS cluster administrator provisions NDS Labs projects (TBD). Tentatively, approved project users will be allocated a Kubernetes namespace, assigned credentials and storage/compute quotas. They will be given an endpoint URL for GUI/CLI access (see below).
Project admin
Prerequisites:
- NDS Labs provisioned project space and credentials
Use cases:
- List available services for deployment
- List available compute/storage quotas
- Add service (e.g., cli add clowder name=myclowder)
- Allocate storage (e.g., cli add vol name=myvol size=1TB)
- Attach storage (e.g., cli attach myvol myclowder)
- Launch services (e.g., cli start myclowder)
- Get endpoint URL
- View logs
- Login to container (e.g., cli exec myclowder bash)
NDS Developer
Prerequisites:
- Docker
Use cases:
- NDS developer can containerize/Dockerize a new service or set of services (i.e., add Dockerfile and associated files to common source/build environment)
- NDS developer can push new versions of Docker images to NDS repository
- NDS developer can test containerized services in NDS Labs test environment
- NDS developer can define Kubernetes configuration for a new service or set of services (i.e., add Pod/RC/Service definitions)
- NDS developer can launch local Kubernetes environment (laptop, single VM)
- NDS developer can add new service definitions to service library
- NDS developer can launch a docker container with all required tools for development (ndsdev container)