This document is out of date and should be removed after confirming that all use cases are represented in JIRA
------Notes from 2/8/16 discussion (Craig, David, Mike)
This is a preliminary set of use cases for the NDS Labs systems 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:
- NDS operationsSite 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 : User of the NDS Labs services. Access the GUI/CLI for managing servicesto 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:
- NDS Operations creates Site administrator creates tenant with sufficient resources (compute/storage) for NDS Labs cluster.
- NDS Operations runs "deployer" Site administrator can start a Kubernetes cluster (NDS-98). They They are prompted to specify the cluster size. The deployer provisions VMs, deploys CoreOS pre-defined OS images, starts docker/ Kubernetes base services.
- NDS Operations starts 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 NDS Operations adds services to services library (TBD). Tentatively, NDS Operations admin must be able to specify add, modify, and remove NDS Labs services available to site usersproject administrators.
- NDS Operations provisions 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).
NDS Project User admin
Prerequisites:
- NDS Labs Provisioned provisioned project space and credentials
...
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)