For testing you will need these in place

• fork buildvm repo
• fork kickstarts repo
• fork puppet-common

• Install libvirt, kvm and qemu locally
• Update your forked buildvm to pull from your forked kickstarts repo
• Update your forked kickstarts to pull from your forked kickstarts
• Update your forked kickstarts to configure networking appropriate for the host on your network
• Clone your forked buildvm script locally and use it to deploy
• Configure halnet to exist in an appropriate format for your network update your own buildvm fork as appropriate

• Ensure your forked repo is up to date with the master repo for the change you are doing (it is unlikely the networking kickstarts will be to be updated - sai)
• Update your configs and push them back to your fork
• Log into the local host and pull the changes (as applicable) from your fork
• For puppet changes run the apply (see root crontab) manually or wait ~15m for it run manually
• For kickstart changes, redeploy the host
• Confirm your changes
• Check /tmp/puppet-apply for status of run

Consideration of this process due to complexity of the change

• Deploy a fresh host
• Wait for it to configure
• Complete a final reboot
• Confirm all configuration is maintained

buildvm will pull the production config from the master branches of the repositories during deploy if you are redeploying to completely test changes the kickstarts will need to be updated to pull from the appropriate repo

This may make sense for some changes. (i am still working though it - sai)

• the production host you will have to be reconfigured to look at the testing branches for all the deployed puppet repos as they will be pointing to the puppet config (perhaps the repofix script should take this into account, we could automate it on hostname naming convention like tupper-testing-<owner> and disarm the repofix while testing - sai)
• potential to rob resources from production