Notes from 2/8/16 discussion (Craig, David, Mike)
This is a preliminary set of use cases for the NDS Labs systems
...
- NDS operations: Infrastructure and cluster administration at NCSA, TACC, SDSC.
- NDS site admin: 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 creates tenant with sufficient resources (compute/storage) for NDS Labs cluster.
- NDS Operations runs "deployer" 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 admin services (NDS-92). These are centralized logging/monitoring services used by NDS Operations across all sites.
- NDS Operations starts NDSLabs services (e.g., API server, GUI service, etc). (TBD)
- NDS Operations 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:
- Site admin adds services to services library (TBD). Tentatively, NDS Operations admin must be able to specify NDS Labs services available to site users.
- NDS Operations Site admin 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 project space and credentials
...