Use cases

Developer installation

After experiencing Labs Workbench via the public demo instance or at a workshop, developers will want to install a local instance to get their hands dirty, understand the architecture and possible integration points with their systems.  We currently offer two approaches to installing Labs Workbench: ndslabs-startup git repo or deploy-tools Ansible playbooks.

• Putting ourselves in the shoes of a developer new to Labs Workbench, are there changes we would make to simplify the local installation? For example, adding support for laptop-deploys with DNS Masq.
• What environments should we support (Linux, Mac, Windows, VMs etc.
• Should we continue to use HyperKube or move to another model (e.g., Minikube)?
• Should we combine ndslabs-startup and deploy-tools into a single container to launch labs workbench?

Labs Workbench Beta

The Labs Workbench beta instance deployed at SDSC is currently configured with 11 instances, 28 vcpus, 196GB RAM, and 1.2 TB storage. This includes ops instance, master, loadbalancer, LMA, two compute nodes, 4 GFS servers, monitoring and backup. Using UC internal pricing, this service will cost an estimate ~$2,100 per month or ~$25,000 per year to run at SDSC under the current configuration.  

• How can we minimize resource requirements and cost while maximizing elasticity and reliability?
• Can we support deployment into other environments (e.g., AWS/GCE)?  
• How can we support deploying labs on existing Kubernetes installations?

TERRA-REF

The TERRA-REF project manages 200TB of data on the ROGER system. Data is accessible via Globus, Clowder, GPFS mount to ROGER batch compute resources, and NFS mount to ROGER/Nebula OpenStack resources.  The TERRA-REF project includes a "tool launcher" service that supports launching Docker containers to analyze data via the Clowder API and mounted directly via NFS.  The "tool launcher" is being replaced by Labs Workbench.  Labs Workbench was also used to support the TERRA-REF Phenome 2017 workshop. On an average day, Labs Workbench will need to support ~5-10 active users.  During workshops, Labs Workbench will need to support ~30 simultaneous users. 

• How can we minimize resource requirements and cost while maximizing elasticity and reliability?

Kubernetes Community-Supported Deployment Options

Users have the option to deploy Kubernetes in a variety of environments: https://kubernetes.io/docs/getting-started-guides/

• Minikube/Ubuntu LXD
• Hosted solutions: 
  • GCE
  • AWS
  • Azure Container Service
• Local solutions
  • kubeadm
  • OpenStack Heat
  • Vagrant/VM/CoreoS Option - Multi Node Kubernetes developer environment - using VBox/Vagrant/CoreOS

• Can/should we support any of these options? What changes would be required to do so?

Tasks

1. Explore deployment of Labs Workbench on laptop or single instance VM. Are there changes we can make to improve the user's experience? What environments can/should we support?
   1. 
   2. 
   3. 
   4. See Developer/Single-node installation
2. Define minimal cluster configuration for current Labs Workbench with ability to scale up/down to support TERRA-REF use case.
   1. 
   2. 
   3. 
   4. See Minimal Workbench Configuration
3. Explore deployment of Labs Workbench on GCE.  What changes are required?
   1. 
   2. See Labs Workbench on GKE
4. Explore deployment of Labs Workbench on AWS. What changes are required?
   1. See 
   2. See Labs Workbench on AWS
5. Explore deployment of Labs Workbench on Azure. What changes are required?
   1. See 
   2. See Labs Workbench on Azure
6. Explore deployment of Labs Workbench on system deployed with kubeadm. What changes are required?
   1. See
   2. See Labs Workbench via Kubeadm
   3. See Multi Node Kubernetes developer environment - using VBox/Vagrant/CoreOS
7. Explore latest options for deploying Kubernetes on OpenStack. What methods would we recommend? Explore deploying Labs Workbench on these environments. What changes would be required?
   1. See 
   2. See Labs Workbench on OpenStack