Loic brought up some good points about EC2 and I'll let that thread continue to discuss those merits. However, there are some things I can still discuss that are needed for LAVA regardless but also happen to fit nicely with Michael's goals.
I spoke to Dave this morning and got some guidance. The easiest way to cover things would be to describe how I'd like to see the lab laid out:
As we know everything goes through "control" and that box is also running LAVA which is not good. So we start with a new system, lets call it "bounce".
* Runs SSHD * Runs apache with mulitiple vhosts set up for reverse proxy.
This could be the new system Dave's setting up now to give access to the TC2s. I looked at the configuration stuff for this and its pretty easy to do. We could prototype it on alternate ports before switching live to ensure there's no lapse of service.
As Michael noted yesterday, it would be nice to grant access to the lab using some type sync with SSH keys of users from a launchpad group. I'm guessing that code has already been written somewhere else before.
We then start taking advantage of our new cloud set up. We currently have 5 System76 systems with specs:
24GB RAM 500GB Disk Intel Xeon X3450 quad core
1 is the cloud controller and the other 4 can run VMs. For LAVA we'll be creating a new VM called "staging". We'll move the staging instance from our control node to this node and also run a dogfood instance of LAVA. We'll also probably create a new instance for our FastModel node.
So up to this point, I'm just covering basic things we need to do for LAVA. To service Michael, we'd:
* grant ssh access to "bounce" * create a VM for him * let him do as he wishes
-andy