User:Bhartshorne~labswiki/Path to a New Project

This page details (from memory because I didn't take notes) the steps I had to go through to get to a running project.

Initial project setup

1. ask the labs gods (aka rlane or andrewbogott) for a new project, got 'swift'
2. go to the instance list and click 'Add Instance'
   • realize I needed a special security group to let other projects access swift and you have to create sec groups before instances
3. go to Manage security groups
   • click 'Add Group'
     • From port and To port indicate a range, not a dest/src port pair.
     • choosing the source IP range - use 0.0.0.0/0 if you want everybody (including public IP addresses if you later give your instance a public IP address), 10.4.0.0/16 if you only want other labs instances connecting. You can use either IPs or groups as the source, not both.
     • create a new security group 'proxy' that allows incoming traffic from port 80 from 0.0.0.0/0
4. go to the instance list and click 'Add Instance'
   • create one instance named 'swift-fe1' in the default and proxy security groups
   • realize it's too slow to create them one at a time,
   • open four tabs with a 'create instance' page in each, create swift-be1 through swift-be4 in only the default security group
5. ssh to my instance
   • I can connect by ID, name, or fqdn.
   • i-000001c3, swift-be2, or swift-be2.pmtpa.wmflabs
6. One of the instances failed to let me in
   • in the instance list, click on 'Get console output' for the instance. See that it didn't build correctly. Delete the instance and start it up again.

Teaching my project about my puppet classes

I needed to get my puppet stuff on the hosts I just started.

1. Get the puppet configs
   • git clone the test repo and make sure I'm in the right branch
   • make some puppet changes to have some configs to pull in to labs
2. Create a puppet group for my project
   • Go to the puppet groups page and create a new group for my project (click 'add group' next to swift)
   • name the group swift-labs and give it position 0 (I don't really know what this means)
3. Add my classes to the group
   • in my case, I wanted to add the role::swift::pmtpa-labs::proxy and role::swift::pmtpa-labs::storage classes; they pull in everything else a swift cluster needs
   • in my puppet group, at classes, click 'add class', then fill in the role::swift::pmtpa-labs::proxy with a class position 0 (again, don't know what this means)
   • do it again for storage. I made them both position 0; it didn't seem to complain. Perhaps just ordering for the UI?
4. Go back to the instance list, click on 'configure' for one of the instances
5. add the appropriate class (the proxy class goes on the frontend, the storage class on the 4 backends), click save.
   • realize this is slow, open a new tab with 'configure' for each of the rest of the instances, add the right class.
6. log into the instance, run 'sudo puppetd -tv' in order to pull down my changes
   • I hit random error: Error 400 on SERVER: Duplicate definition: Sshkey[10.4.0.2] is already defined in file /etc/puppet/manifests/ssh.pp at line 36. After waiting 30 seconds and trying again, it went away.
   • Other errors were legit

Applying my puppet changes

Time to iterate

1. make a change in the puppet configs, check it in, push it to gerrit, review it in gerrit, merge it with the test branch
2. wait 10-60 seconds
3. run sudo puppetd -tv on an instance

Done

At this point, stuff I did to make my service work were entirely service dependent and not related to the labs infrastructure (much). I did have to disable the iptables puppet rules for some reason, but I don't know if that was a config error on my part. The trick if $realm == 'labs' (or, inversely, != 'labs') made it easy to just comment out sections of the puppet configs that were relevant to hardware but not labs.