[{"_1":2,"_188":-5,"_189":-5},"loaderData",{"_3":4,"_13":14,"_20":21,"_163":164},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":11,"_17":18,"_19":11},"username","isBillingDecouplingSeatCount","isAskGordonEnabled",true,"isUsingNewTemplate","routes/_layout.r.$namespace.$reponame",{"_22":23,"_24":-5,"_25":11,"_26":11,"_27":28,"_29":30,"_31":-5,"_32":11,"_33":34,"_83":84,"_108":109,"_156":-5,"_157":11,"_158":11,"_159":11,"_160":-5,"_161":162},"canonicalUrl","https://hub.docker.com/r/unidata/xsede-jetstream/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","unidata","reponame","xsede-jetstream","cloudBuildSource","isAutobuildsAvailable","repo",{"_35":36,"_37":38,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":50,"_52":30,"_27":28,"_53":54,"_55":39,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":28,"_68":69,"_74":18,"_75":76,"_80":28,"_81":82},"categories",[],"content_types",[39],"image","date_registered","2017-04-25T19:40:36.63818Z","description","Unidata on the XSEDE Jetstream Cloud\n","is_private","last_updated","2020-04-18T04:07:22.3464Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[51],"application/vnd.docker.container.image.v1+json","name","pull_count",163409,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","- [Running VMs on Jetstream with OpenStack](#h-90A8A74D)\n - [Introduction](#h-11F59F95)\n - [Install Docker (Do This Once)](#h-DE5B47F1)\n - [Clone the science-gateway Repository (Do This Once)](#h-968FA51C)\n - [Pull or Build Docker Container (Do This Once)](#h-4A9632CC)\n - [Pull Container](#h-B5690030)\n - [Build Container](#h-1C54F677)\n - [API Setup](#h-CBD5EC54)\n - [Download and Edit openrc.sh (Do This Once)](#h-8B3E8EEE)\n - [Fire Up Container and More Setup](#h-30B73273)\n - [Working with Jetstream API to Create VMs](#h-03303143)\n - [IP Numbers](#h-5E7A7E65)\n - [Boot VM](#h-EA17C2D9)\n - [Create and Attach Data Volumes](#h-9BEEAB97)\n - [Opening TCP Ports](#h-D6B1D4C2)\n - [Tearing Down VMs](#h-1B38941F)\n - [Swapping VMs](#h-56B1F4AC)\n - [Building a Kubernetes Cluster](#h-DA34BC11)\n - [Define cluster with cluster.tf](#h-F44D1317)\n - [Create VMs with kube-setup.sh](#h-0C658E7B)\n - [Install Kubernetes with kube-setup2.sh](#h-05F9D0A2)\n - [Check Cluster](#h-D833684A)\n - [Adding Nodes to Cluster](#h-1991828D)\n - [Removing Nodes from Cluster](#h-0324031E)\n - [Tearing Down the Cluster](#h-DABDACC7)\n - [Monitoring the Cluster with Grafana and Prometheus](#h-005364BF)\n - [Patching Master Node](#h-1B2FF6A7)\n- [Appendix](#h-78283D4A)\n - [Jetstream VM Flavors](#h-958EA909)\n\n\n\n\n\n# Running VMs on Jetstream with OpenStack\n\n\n\n\n## Introduction\n\nIt is preferable to interface with the NSF Jetstream cloud via the [Atmosphere web interface](https://use.jetstream-cloud.org/application/dashboard). However, this web dashboard is limited in two important ways:\n\n1. Users cannot obtain VMs with static IPs\n2. Users cannot open low number ports (i.e., < `1024`) with the exception of ports `22`, `80` and `443` which are open by default.\n\nIf you are in either of these scenarios, you have to interface with Jetstream via the [OpenStack API](https://iujetstream.atlassian.net/wiki/display/JWT/Using+the+Jetstream+API). The problem here is that there is some initial setup which is somewhat painful but that you do only once. We provide a Docker container that hopefully eases some of the pain as it has the OpenStack command line tools and convenience scripts installed. After that setup, you can interface with the Jetstream OpenStack command line via the `openstack.sh` script which will launch a Docker container that will enable you to:\n\n- Create IP Numbers\n- Create VMs\n- Tear down VMs\n- Create Data Volumes\n- Attach Data Volumes\n- Open TCP ports\n\nNote, you do not have to employ this Docker container. It is merely provided as a convenience. If you choose, you can go through the Jetstream OpenStack API instructions directly and ignore all that follows.\n\n\n\n\n## Install Docker (Do This Once)\n\n[Install Docker](../vm-init-readme.md) in your computing environment because we will be interacting with the OpenStack Jetstream API via Docker. This step should make our lives easier.\n\n\n\n\n## Clone the science-gateway Repository (Do This Once)\n\nWe will be making heavy use of the `Unidata/science-gateway` git repository.\n\n```sh\ngit clone https://github.com/Unidata/science-gateway\n```\n\n\n\n\n## Pull or Build Docker Container (Do This Once)\n\n```sh\ncd science-gateway/openstack\n```\n\nAt this point, you can either pull or build the `science-gateway` container:\n\n\n\n\n### Pull Container\n\n```sh\ndocker pull unidata/science-gateway\n```\n\n\n\n\n### Build Container\n\n```sh\ndocker build -t unidata/science-gateway .\n```\n\n\n\n\n## API Setup\n\nWe will be using the Jetstream API directly and via convenience scripts.\n\n\n\n\n### Download and Edit openrc.sh (Do This Once)\n\nThe next part involves downloading the `openrc.sh` file to work with our OpenStack allocation. You will have first login to the OpenStack TACC dashboard which will necessitate a password reset. Unfortunately, this login is not the same as the Jetstream Atmosphere web interface login. Also, follow the usual password advice of not reusing passwords as this password will end up in your OpenStack environment and [you may want to add it](#h-9C0700C5) in the `openrc.sh` file for convenience.\n\n1. [Reset your OpenStack TACC dashboard password](https://portal.tacc.utexas.edu/password-reset/)\n\n2. Download your `openrc.sh` file from the IU (not TACC) dashboard at and move it to the `openstack/bin` directory.\n\n - See *\"Use the Horizon dashboard to generate openrc.sh\"* in the [Jetstream API instructions](https://iujetstream.atlassian.net/wiki/display/JWT/Setting+up+openrc.sh).\n - From the [IU dashboard](https://iu.jetstream-cloud.org/project/api_access/), navigate to `Project`, `API Access`, then select `Download OpenStack RC File` at top-right.\n - Select **OpenStack RC File (Identity API 3)** , which will download as a script named something like `TG-ATM160027-openrc.sh`. You should rename it to `openrc.sh`.\n - Move this file to `bin/openrc.sh` (e.g., `/home/jane/science-gateway/openstack/bin/openrc.sh`).\n\n3. Edit `bin/openrc.sh` Password (Optional)\n\n For convenience, you may wish to add your password to the `openrc.sh` file. Again, follow the usual advice of not reusing passwords as this password will end up in your OpenStack environment.\n\n Edit the `openrc.sh` file and the supply the TACC resource `OS_PASSWORD` you [reset earlier](#h-8B3E8EEE):\n\n ```sh\n export OS_PASSWORD=\"changeme!\"\n ```\n\n Comment out\n\n ```sh\n # echo \"Please enter your OpenStack Password: \"\n # read -sr OS_PASSWORD_INPUT\n ```\n\n\n\n\n### Fire Up Container and More Setup\n\n1. openstack.sh\n\n Start the `unidata/science-gateway` container with `openstack.sh` convenience script. The script take a `-o` argument for your `openrc.sh` file and a `-s` argument for the directory containing or will contain your ssh keys (e.g., `/home/jane/science-gateway/openstack/ssh` or a new directory that will contain contain your Jetstream OpenStack keys that we will be creating shortly). **Both arguments must be supplied with fully qualified path names.**\n\n ```sh\n chmod +x openstack.sh\n ./openstack.sh -o -s \n ```\n\n Subsequently, when interacting with Jetstream via OpenStack API now and in the future, you will be using this container to create VMs, mount volumes, etc.\n\n A wrapper script `run.sh` is provided, which assumes that directories `bin/` and `ssh/` exist in the working directory, and that `bin/` contains `openrc.sh`:\n\n ```sh\n ./run.sh\n ```\n\n You can use this `run.sh` script as a template for you to parameterize, perhaps for alternative `openrc.sh` files.\n\n2. Create ssh Keys (Do This Once)\n\n This step of ssh key generation is important. In our experience, we have not had good luck with preexisting keys. You may have to generate a new one. Be careful with the `-f` argument below. We are operating under one allocation so make sure your key names do not collide with other users. Name your key something like `-${OS_PROJECT_NAME}-api-key`. Then you add your public key the TACC dashboard with `openstack keypair create`.\n\n ```sh\n cd ~/.ssh\n ssh-keygen -b 2048 -t rsa -f -P \"\"\n openstack keypair create --public-key .pub \n # go back to home directory\n cd\n ```\n\n The `ssh` directory was mounted from outside the Docker container you are currently running. Your public/private key should be saved there. Don't lose it or else you may not be able to delete the VMs you are about to create.\n\n3. Testing Setup\n\n At this point, you should be able to run `openstack image list` which should yield something like:\n\n | ID | Name |\n |------------------------------------ |---------------------------------- |\n | fd4bf587-39e6-4640-b459-96471c9edb5c | AutoDock Vina Launch at Boot |\n | 02217ab0-3ee0-444e-b16e-8fbdae4ed33f | AutoDock Vina with ChemBridge Data |\n | b40b2ef5-23e9-4305-8372-35e891e55fc5 | BioLinux 8 |\n\n If not, check your setup.\n\n\n\n\n## Working with Jetstream API to Create VMs\n\nAt this point, we are past the hard work. You will employ the `unidata/science-gateway` container accessed via the `openstack.sh` convenience script to\n\n- Create IP Numbers\n- Create VMs\n- Tear down VMs\n- Create Data Volumes\n- Attach Data Volumes\n\nIf you have not done so already:\n\n```sh\n./openstack.sh -o -s \n```\n\n\n\n\n### IP Numbers\n\nWe are ready to fire up VMs. First create an IP number which we will be using shortly:\n\n```sh\nopenstack floating ip create public\nopenstack floating ip list\n```\n\nor you can just `openstack floating ip list` if you have IP numbers left around from previous VMs.\n\n\n\n\n### Boot VM\n\n1. Create VM\n\n Now you can boot up a VM with something like the following command:\n\n ```sh\n boot.sh -n unicloud -k -s m1.medium -ip 149.165.157.137\n ```\n\n The `boot.sh` command takes a VM name, [ssh key name](#h-EE48476C) defined earlier, size, and IP number created earlier, and optionally an image UID which can be obtained with `openstack image list | grep -i featured`. Note that these feature VMs are recommended by Jetstream staff, and have a default user corresponding to the Linux distribution flavor. For example,\n\n ```sh\n $ openstack image list | grep -i featured\n ```\n\n may yield something like:\n\n ```sh\n | 4ada5750-4ba4-4cc6-8d12-9001fe04ae1b | JS-API-Featured-Centos6-Feb-13-2018 |\n | 87df53d5-04bd-4bb8-862e-b67247f07f87 | JS-API-Featured-Centos7-Feb-13-2018 |\n | 20e6ec66-a5ec-41fc-820c-08a2af5bd1eb | JS-API-Featured-Ubuntu14-Feb-13-2018 |\n | a2c80fbf-2875-457a-b488-28c4afeb296b | JS-API-Featured-Ubuntu16-Feb-13-2018 |\n ```\n\n The CentOS VMs will have a default of user `centos` and the Ubuntu VMs will have a default user of `ubuntu`.\n\n Also see `boot.sh -h` and `openstack flavor list` for more information.\n\n2. SSH Into New VM\n\n At this point, you can `ssh` into our newly minted VM. Explicitly providing the key name with the `ssh` `-i` argument and a user name (e.g., `ubuntu` or `centos`) may be important:\n\n ```sh\n ssh -i ~/.ssh/ ubuntu@149.165.157.137\n ```\n\n At this point, you might see\n\n ```sh\n ssh: connect to host 149.165.157.137 port 22: No route to host\n ```\n\n Usually waiting for a few minutes resolves the issue. If you are still have trouble, try `openstack server stop ` followed by `openstack server start `.\n\n3. Adding Additional SSH Keys (Optional)\n\n Once you are in your VM, it is probably best to add additional ssh public keys into the `authorized_keys` file to make logging in easier from whatever host you are connecting from.\n\n\n\n\n### Create and Attach Data Volumes\n\nYou can create data volumes via the OpenStack API. As an example, here, we will be creating a 750GB `data` volume. You will subsequently attach the data volume:\n\n```sh\nopenstack volume create --size 750 data\n\nopenstack volume list && openstack server list\n\nopenstack server add volume

\n```\n\nYou will then be able to log in to your VM and mount your data volume with typical Unix `mount`, `umount`, and `df` commands. If running these command manually (not using the `mount.sh` script) you will need to run `kfs.ext4 /dev/sdb` to create an `ext4` partition using the entire disk.\n\nThere is a `mount.sh` convenience script to mount **uninitialized** data volumes. Run this script as root or `sudo` on the newly created VM not from the OpenStack CL.\n\n1. Ensure Volume Availability Upon Machine Restart\n\n You want to ensure data volumes are available when the VM starts (for example after a reboot). To achieve this objective, you can run this command which will add an entry to the `/etc/fstab` file:\n\n ```shell\n echo UUID=2c571c6b-c190-49bb-b13f-392e984a4f7e /data ext4 defaults 1 1 | tee \\\n --append /etc/fstab > /dev/null\n ```\n\n where the `UUID` represents the ID of the data volume device name (e.g., `/dev/sdb`) which you can discover with the `blkid` (or `ls -la /dev/disk/by-uuid`) command. [askubuntu](https://askubuntu.com/questions/164926/how-to-make-partitions-mount-at-startup-in-ubuntu-12-04) has a good discussion on this topic.\n\n\n\n\n### Opening TCP Ports\n\nOpening TCP ports on VMs must be done via OpenStack with the `openstack security group` command line interfaces. In addition, this can be For example, to create a security group that will enable the opening of TCP port `80`:\n\n```sh\nsecgroup.sh -n my-vm-ports -p 80\n```\n\nOnce the security group is created, you can attach multiple TCP ports to that security group with `openstack security group` commands. For example, here we are attaching port `8080` to the `global-my-vm-ports` security group.\n\n```sh\nopenstack security group rule create global-my-vm-ports --protocol tcp --dst-port 8080:8080 --remote-ip 0.0.0.0/0\n```\n\nFinally, you can attach the security group to the VM (e.g., `my-vm`) with:\n\n```sh\nopenstack server add security group my-vm global-my-vm-ports\n```\n\n\n\n\n### Tearing Down VMs\n\n1. umount External Volumes\n\n There is also a `teardown.sh` convenience script for deleting VMs. Be sure to `umount` any data volumes before deleting a VM. For example on the VM in question,\n\n ```sh\n umount /data\n ```\n\n You may have to verify, here, that nothing is writing to that data volume such as Docker or NFS (e.g., `docker-compose stop`, `sudo service nfs-kernel-server stop`), in case you get errors about the volume being busy.\n\n In addition, just to be on the safe side, remove the volume from the VM via OpenStack:\n\n ```sh\n openstack volume list && openstack server list\n\n openstack server remove volume

\n ```\n\n2. Tear Down\n\n Then finally from the OpenStack CL,\n\n ```sh\n teardown.sh -n unicloud -ip 149.165.157.137\n ```\n\n For now, you have to supply the IP number even though the script should theoretically be smart enough to figure that out.\n\n\n\n\n### Swapping VMs\n\nCloud-computing promotes the notion of the throwaway VM. We can swap in VMs that will have the same IP address and attached volume disk storage. However, before swapping out VMs, we should do a bit of homework and careful preparation so that the swap can go as smoothly as possible.\n\n1. Prerequisites\n\n Create the VM that will be swapped in. Make sure to:\n\n - [initialize new VM](../vm-init-readme.md)\n - build or fetch relevant Docker containers\n - copy over the relevant configuration files. E.g., check with `git diff` and scrutinize `~/config`\n - check the crontab with `crontab -l`\n - beware of any `10.0` address changes that need to be made (e.g., NFS mounts)\n - consider other ancillary stuff (e.g., check home directory, `docker-compose` files)\n - think before you type\n\n2. /etc/fstab and umount\n\n Examine `/etc/fstab` to find all relevant mounts on \"old\" VM. Copy over `fstab` to new host (the `UUIDs` should remain the same but double check). Then `umount` mounts.\n\n3. OpenStack Swap\n\n From the OpenStack command line, identify the VM IDs of the old and new VM as well as any attached external volume ID:\n\n ```shell\n openstack volume list && openstack server list\n ```\n\n Then swap out both the IP address as well as zero or more external data volumes with the new server.\n\n ```shell\n\n openstack server remove floating ip ${VM_ID_OLD} ${IP}\n openstack server add floating ip ${VM_ID_NEW} ${IP}\n\n for i in ${VOLUME_IDS}\n do\n openstack server remove volume ${VM_ID_OLD} $i\n openstack server add volume ${VM_ID_NEW} $i\n done\n ```\n\n4. /etc/fstab and mount\n\n Issue `blkid` (or `ls -la /dev/disk/by-uuid`) command to find `UUIDs` that will be inserted into the `/etc/fstab`. Lastly, `mount -a`.\n\n\n\n\n## Building a Kubernetes Cluster\n\nIt is possible to create a Kubernetes cluster with the Docker container described here. We employ [Andrea Zonca's modification of the kubespray project](https://github.com/zonca/jetstream_kubespray). Andrea's recipe to build a Kubernetes cluster on Jetstream with kubespray is described [here](https://zonca.github.io/2018/09/kubernetes-jetstream-kubespray.html). These instructions have been codified with the `kube-setup.sh` and `kube-setup2.sh` scripts.\n\nMake sure to run both `kubectl` and `helm` from the client and `ssh` tunnel (`ssh ubuntu@FLOATINGIPOFMASTER -L 6443:localhost:6443`)into the master node as described in the instructions.\n\n\n\n\n### Define cluster with cluster.tf\n\nFirst, modify `~/jetstream_kubespray/inventory/zonca/cluster.tf` to specify the number of nodes in the cluster and the size ([flavor](#h-958EA909)) of the VMs. For example,\n\n```sh\n# nodes\nnumber_of_k8s_nodes = 0\nnumber_of_k8s_nodes_no_floating_ip = 2\nflavor_k8s_node = \"4\"\n```\n\nwill create a 2 node cluster of `m1.large` VMs. [See Andrea's instructions for more details](https://zonca.github.io/2018/09/kubernetes-jetstream-kubespray.html).\n\n[This spreadsheet](https://docs.google.com/spreadsheets/d/15qngBz4L5gwv_JX9HlHsD4iT25Odam09qG3JzNNbdl8/edit?usp=sharing) will help you determine the size of the cluster based on number of users, desired cpu/user, desired RAM/user. Duplicate it and adjust it for your purposes.\n\n`openstack flavor list` will give the IDs of the desired VM size.\n\nAlso, note that `cluster.tf` assumes you are building a cluster at the TACC data center with the sections pertaining to IU commented out. If you would like to set up a cluster at IU, make the necessary modifications located at the end of `cluster.tf`.\n\n**IMPORTANT**: once you define an `image` (e.g., `image = JS-API-Featured-Ubuntu18-May-22-2019`) or a flavor size (e.g., `flavor_k8s_master = 2`), make sure you do not subsequently change it after you have run Terraform and Ansible! This scenario can happen when [adding cluster nodes](#h-1991828D) and the featured image no longer exists because it has been updated. If you must change these values, you'll first have to [preserve your application data](../vms/jupyter/readme.md#h-5F2AA05F) and do a [gentle - IP preserving - cluster tear down](#h-DABDACC7) before rebuilding it and re-installing your application.\n\n\n\n\n### Create VMs with kube-setup.sh\n\nAt this point, to create the VMs that will house the kubernetes cluster (named \"k8s-unidata\", for example) run\n\n`kube-setup.sh -n k8s-unidata`\n\nThis script essentially wraps Terraform install scripts to launch the VMs according to `cluster.tf`.\n\nOnce, the script is complete, let the VMs settle for a while (let's say ten minutes). Behind the scenes `dpkg` is running on the newly created VMs which can take some time to complete.\n\n1. Check Status of VMs\n\n Check to see the status of the VMs with:\n\n ```sh\n openstack server list | grep k8s-unidata\n ```\n\n and\n\n ```sh\n watch -n 15 \\\n ansible -i $HOME/jetstream_kubespray/inventory/k8s-unidata/hosts -m ping all\n ```\n\n 1. Steps if VMs are Unhappy\n\n If the check status process did not go smoothly, here are some thing you can try to remedy the problem.\n\n If you see any errors, you can try to wait a bit more or reboot the offending VM with:\n\n ```sh\n openstack server reboot \n ```\n\n or you can reboot all VMs with:\n\n ```sh\n osl | grep k8s-unidata | awk '{print $2}' | xargs -n1 openstack server reboot\n ```\n\n If VMs stuck in `ERROR` state. You may be able to fix this problem with:\n\n ```sh\n cd ~/jetstream_kubespray/inventory/k8s-unidata/\n CLUSTER=k8s-unidata bash -c 'sh terraform_apply.sh'\n ```\n\n or you can destroy the VMs and try again\n\n ```sh\n cd ~/jetstream_kubespray/inventory/k8s-unidata/\n CLUSTER=k8s-unidata bash -c 'sh terraform_destroy.sh'\n ```\n\n\n\n\n### Install Kubernetes with kube-setup2.sh\n\nNext, run\n\n```sh\nkube-setup2.sh -n k8s-unidata\n```\n\nIf seeing errors related to `dpkg`, wait and try again or [try these steps](#h-F4401658).\n\nRun `kube-setup2.sh -n k8s-unidata` again.\n\n\n\n\n### Check Cluster\n\nEnsure the Kubernetes cluster is running:\n\n```\nkubectl get pods --all-namespaces\n```\n\nand get a list of the nodes:\n\n```sh\nkubectl get nodes --all-namespaces\n```\n\n\n\n\n### Adding Nodes to Cluster\n\nYou can augment the computational capacity of your cluster by adding nodes. In theory, this is just a simple matter of [adding worker nodes](#h-F44D1317) in `jetstream_kubespray/inventory/k8s-unidata/cluster.tf` followed by running:\n\n```sh\ncd ~/jetstream_kubespray/inventory/k8s-unidata/\nCLUSTER=k8s-unidata bash -c 'sh terraform_apply.sh'\n```\n\nWait a bit to allow `dpkg` to finish running on the new node(s). [Check the VMS](#h-136A4851). Next:\n\n```sh\ncd ~/jetstream_kubespray\nCLUSTER=k8s-unidata bash -c 'sh k8s_scale.sh'\n```\n\n[Check the cluster](#h-D833684A).\n\n\n\n\n### Removing Nodes from Cluster\n\nIt is also possible to remove nodes from a Kubernetes cluster. First see what nodes are running:\n\n```sh\nkubectl get nodes --all-namespaces\n```\n\nwhich will yield something like:\n\n```sh\nNAME STATUS ROLES AGE VERSION\nk8s-unidata-k8s-master-1 Ready master 42h v1.12.5\nk8s-unidata-k8s-node-nf-1 Ready node 42h v1.12.5\nk8s-unidata-k8s-node-nf-2 Ready node 41h v1.12.5\n```\n\nFrom the Kubernetes master node:\n\n```sh\ncd ~/jetstream_kubespray\nCLUSTER=k8s-unidata bash -c 'sh k8s_remove_node.sh k8s-unidata-k8s-node-nf-2'\n```\n\nfollowed by running:\n\n```sh\nteardown.sh -n k8s-unidata-k8s-node-nf-2\n```\n\nfrom the openstack command line.\n\n[Check the cluster](#h-D833684A).\n\n\n\n\n### Tearing Down the Cluster\n\n1. Without Preserving IP of Master Node\n\n Once you are finished with your Kubernetes cluster you can completely wipe it out (think before you type and make sure you have the cluster name correct):\n\n ```sh\n cd ~/jetstream_kubespray/inventory/k8s-unidata/\n CLUSTER=k8s-unidata bash -c 'sh terraform_destroy.sh'\n ```\n\n2. With Preserving IP of Master Node\n\n You can also tear down your cluster but still preserve the IP number of the master node. This is useful and important when the IP of the master node is associated with a DNS name that you wish to keep associated.\n\n ```sh\n cd ~/jetstream_kubespray/inventory/k8s-unidata/\n CLUSTER=k8s-unidata bash -c 'sh terraform_destroy_keep_floatingip.sh'\n ```\n\n Subsequently, when you invoke `terraform_apply.sh`, the master node should have the same IP number as before.\n\n **Note**: AFTER invoking `terraform_apply.sh` remove the `~/.ssh/known_hosts` line that corresponds to the old master node! This can easily be achieved by sshing into the new master node which will indicate the offending line in `~/.ssh/known_hosts`. This will avoid headaches when invoking `kube-setup2.sh`.\n\n\n\n\n### Monitoring the Cluster with Grafana and Prometheus\n\n[Grafana](https://grafana.com/) is a monitoring engine equipped with nice dashboards and fancy time-series visualizations. [Prometheus](https://github.com/camilb/prometheus-kubernetes) allows for monitoring of Kubernetes clusters.\n\nInstalling these monitoring technologies is fairly straightforward and [described here](https://zonca.github.io/2019/04/kubernetes-monitoring-prometheus-grafana.html).\n\n\n\n\n### Patching Master Node\n\nYou'll want to keep the master node security patched as it will have a publicly accessible IP number attached to a well known DNS name. If you see packages out of date upon login, as root user:\n\n```sh\n apt-get update && apt-get -y upgrade && apt-get -y dist-upgrade \\\n && apt autoremove -y\nreboot -h now\n```\n\n\n\n\n# Appendix\n\n\n\n\n## Jetstream VM Flavors\n\n| ID | Name | RAM(GB) | Disk(GB) | VCPUs |\n|--- |---------- |------- |-------- |----- |\n| 1 | m1.tiny | 2 | 8 | 1 |\n| 2 | m1.small | 4 | 20 | 2 |\n| 3 | m1.medium | 16 | 60 | 6 |\n| 4 | m1.large | 30 | 60 | 10 |\n| 5 | m1.xlarge | 60 | 60 | 24 |\n| 6 | m1.xxlarge | 120 | 60 | 44 |\n| 14 | s1.large | 30 | 120 | 10 |\n| 15 | s1.xlarge | 60 | 240 | 24 |\n| 16 | s1.xxlarge | 120 | 480 | 44 |\n","has_starred","hub_user","immutable_tags_settings",{"_70":11,"_71":72},"enabled","rules",[73],".*","is_automated","permissions",{"_77":18,"_78":11,"_79":11},"read","write","admin","user","storage_size",70370712340,"orgData",{"_85":86,"_87":88,"_89":90,"_91":28,"_92":93,"_94":95,"_96":93,"_97":98,"_99":100,"_101":102,"_103":104,"_105":106,"_107":18},"id","2354cf5a9b634962b6ffbd891636318a","uuid","2354cf5a-9b63-4962-b6ff-bd891636318a","type","organization","orgname","full_name","NSF Unidata","location","Boulder, Colorado USA","company","profile_url","http://www.unidata.ucar.edu/","date_joined","2015-02-04T00:07:24.635Z","gravatar_url","https://www.gravatar.com/avatar/f0ddba26f2eb351c7f46434fb5b5f693?s=80&r=g&d=mm","gravatar_email","","badge","open_source","is_active","recentTags",[110,146],{"_111":39,"_112":113,"_114":115,"_85":116,"_117":118,"_45":135,"_136":113,"_137":28,"_138":51,"_52":139,"_140":141,"_142":126,"_143":135,"_144":61,"_145":18},"content_type","creator",210021,"full_size",472425192,10303265,"images",[119],{"_120":121,"_122":123,"_124":104,"_125":126,"_127":128,"_129":130,"_131":104,"_132":-5,"_133":115,"_58":61,"_134":-5},"architecture","amd64","digest","sha256:b6e6338464c159c87d29f134e9ab5d7ff8f9a180d7e80b07f48b6e3cca81df07","features","last_pulled","2026-07-21T02:47:37.521459944Z","last_pushed","2020-04-18T04:07:22Z","os","linux","os_features","os_version","size","variant","2020-04-18T04:07:22.026927Z","last_updater","last_updater_username","media_type","latest","repository",1438128,"tag_last_pulled","tag_last_pushed","tag_status","v2",{"_111":39,"_112":113,"_114":147,"_85":148,"_117":149,"_45":154,"_136":113,"_137":28,"_138":51,"_52":155,"_140":141,"_142":152,"_143":154,"_144":61,"_145":18},156725328,10302234,[150],{"_120":121,"_122":151,"_124":104,"_125":152,"_127":153,"_129":130,"_131":104,"_132":-5,"_133":147,"_58":61,"_134":-5},"sha256:7232b5818cc61556b236507ce2db590d868ac51b76cf60f1255b4bbddc158dd5","2026-07-21T02:47:38.164777484Z","2017-05-15T23:39:45Z","2017-05-15T23:39:44.726227Z","v0.1.0","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_33":165,"_172":173,"_161":186,"_187":11},{"_35":166,"_37":167,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":168,"_52":30,"_27":28,"_53":54,"_55":39,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":28,"_68":169,"_74":18,"_75":171,"_80":28,"_81":82},[],[39],[51],{"_70":11,"_71":170},[73],{"_77":18,"_78":11,"_79":11},"tags",{"_174":175,"_176":-5,"_177":-5,"_178":179},"count",2,"next","previous","results",[180,183],{"_111":39,"_112":113,"_114":115,"_85":116,"_117":181,"_45":135,"_136":113,"_137":28,"_138":51,"_52":139,"_140":141,"_142":126,"_143":135,"_144":61,"_145":18},[182],{"_120":121,"_122":123,"_124":104,"_125":126,"_127":128,"_129":130,"_131":104,"_132":-5,"_133":115,"_58":61,"_134":-5},{"_111":39,"_112":113,"_114":147,"_85":148,"_117":184,"_45":154,"_136":113,"_137":28,"_138":51,"_52":155,"_140":141,"_142":152,"_143":154,"_144":61,"_145":18},[185],{"_120":121,"_122":151,"_124":104,"_125":152,"_127":153,"_129":130,"_131":104,"_132":-5,"_133":147,"_58":61,"_134":-5},[],"canDeleteTags","actionData","errors"]

unidata/xsede-jetstream

Tags for unidata/xsede-jetstream