Removing a Hub - questions about hub-ops

[betatim]

(1) I think this is the state we have for WSHUB now. To reactivate it you need to do #67 in reverse and then it should be back in action. When you are done you need to follow the "remove a hub" instructions again. After that it costs no money anymore and can be brought back to life quickly.

(2) I think for July the bill is ~$200. Did some tuning of resources in #76 with the goal of getting to $100 per month for the "no one is using anything but hubs are ready for users to login". How low we can get this number will depend a bit on how many hubs we want to be "at the ready" (ie people can just login to them) and what we think is an acceptable experience for the first person to login. If we make the "core" as cheap as possible then the first user that logs in each morning will have to wait ~8-10minutes for a new VM to startup. Or we spend a bit more so that one person can login without having to wait (which probably covers a large number of use cases). Or we spend even more so that N people can login without having to wait. "Less waiting on login" -> more $$

(3) you can install kubectl, helm and gcloud on your laptop or use the terminal in console.cloud.google.com. Up to you. There is https://earthlab-hub-ops.readthedocs.io/en/latest/tooling.html which gives some pointers on how to install them on your laptop.

[betatim]

(2) again: I expect that as we gain experience with students around we can get more adventurous in squeezing the bill. I'd start with something which is on the generous side, observe the actual usage patterns for a week or two, then see where we can squeeze.

The autoscaling itself is a feature of the "node pool" (scroll to the bottom, should say "core-pool"). We can configure the min&max size of the pool and what kind of machines it uses. When the current machines are full it will launch a new one, and as people's notebook pods are stopped it will turn off machines again.

My expectation right now is that we have two pools. One that is "always on" and is home to the hub pods and monitoring pods. A second pool that can scale to zero which uses a machine type big enough for about 15 students. So we only need to start a new machine for every 15 or so students. Right now the machine in the "core-pool" has just enough room so that one person can start a user pod and not trigger a scale up event. If this works well it would seem like the best of both worlds.

[lwasser]

ok thank you... this helps. i'll go through the tooling section to better understand a local setup. leaving this open for the time being to reference!