I worked on this for $dayjob. I'm using it for generating builder nodes and other similar 'disposable' nodes on a local cluster of kvm/virtd servers.
Obviously this is just an example but having this with a git repo of my playbooks and configs make managing that set of systems easy and [re]installing them trivial.
http://fedorapeople.org/cgit/skvidal/public_git/scripts.git/tree/ansible/start-prov-boot.py
Just thought I'd put it out here as it might be useful as a basis for other scripts.
-sv
Thanks for sharing this Seth.
I've been mulling over playbooks w/ specialized modules vs scripts like this one that orchestra. What's the right thing to use and when?
I've been struggling with orchestrating what I need to do as I try and write some plays with a bit more complex data and logic. In Python these are pretty easy and straight forward. At the same time I don't want create a hacked up mess or inadvertently paint myself in to the proverbial corner.
What's everyone's take on this been?
<tim/>
Wow, very very cool. Some parallels to this: https://github.com/dsander/vagrant-ansible (which only uses VirtualBox, and I haven't tried it out)
Something generic to support all possible types of virtualization would be uber-slick, but I also recognize that's a crazy ton of work and you have basically built a generic cloud solution at this point.
"More nodes please… boom"
--Michael
Sounds like you’re talking about a plugin for libcloud that handles non-cloud virtual stacks. A casual Google suggests people are talking about VirtualBox support in libcloud already.
So - in writing it I realized I could have implemented something similar a dozen different ways using any number of the tools. However, all of them required I do things in advance I didn't want to do.
Ansible let me spin up a pretty generic rhel6 instance with @core installed on it and the only other thing being it sucking down my authorized_keys and enabling root login w/keys.
Instead of having to precreate an image the way I wanted it and just instantiate that over and over again.
I like the 'purity' of doing it via kickstart.
the scripts which clean an ec2 or rackspace image make me uncomfortable. I've read them, they do a good job but none of them are PERFECTLY clean.
kickstart is perfectly clean.
-sv
Right now - I like using python as the flow-control mechanism for which playbooks to run. It lets me have much better control over host statuses and for a builder script I've been working on it lets me launch builds in an async ansible job and check on its status occasionally while doing other things.
I don't know if it is anything that was originally intended but it does seem to work pretty well.
-sv
Wasn't really. I find virtualbox to be mostly a testing thing. More thinking about EC2.
I basically pondering stuff like "hey scale up my nodes in this group to this many". "Now go reconfigure my web servers and load balancer"
Not something I have bandwidth to chase, pretty content to sticking to the config layer here.
--Michael
spinning up more ec2 (or gce or RAX) nodes via script should be UTTERLY trivial, imo. And tying it up to ansible is really quite easy.
I'm not sure I really want to write something generic enough to work with ANY of them but I'm sure it is doable.
Essentially you'd just want to replace the section of my script that launches virt-install with something that just calls out to boto or libcloud and starts and instance and waits for the ip addr back.
Once you have the ip - just watch until sshd is answering and hit it with a playbook.
Spawning N of those instances and shoving all of them into the host_list to pass to an playbook object is, obviously, TRIVIAL 
-sv
Wow, very very cool. Some parallels to this: https://github.com/dsander/vagrant-ansible (which only uses VirtualBox, and I haven't tried it out)
This is great, btw. I had just written my own little chunk of code
to use ansible as a vagrant provisioner last week.
Why do I always forget to search github...
Thanks,
Curtis.
Hi skv,
(Also: Hello list. That's my first post here so greetings to everyone!)
Your Python program is a great inspiration, thanks! I plan to do something similar for provisioning of Debian (Squeeze) VMs with Ansible but that requires a mechanism called 'preseed' instead of kickstart in Fedora/RedHat land. So one way to reach this goal would be to take your script and adapt it to my Debian-wise needs. Another way would be, to just extend the Ansible 'virt' module to support more or less the same functionality your script provides: define new VMs/libvirt-domains, boot/start them (both can be done by using virt-install under the hood like you do). The last step - nothing that would involve Ansible directly - would be to provide a local PXE server with the Debian Squeeze network boot image and the preseed configuration file. The second way would give this new functionality - creating new VMs per Ansible definitions - to all Ansible users ...
I'd be quite interested in making sure the virt module is happy on Debian, though since it's already using libvirt, I would expect that to be almost a no-op, if not already that.
So why you decided to write an own script to accomplish the provisioning of KVMs? Any reasons you haven't extended the Ansible 'virt' module?
I would be interested in seeing what this would look like, but I can't say I'll take it unless I like what it looks like.
Being able to invoke a virt-install command and wait for it with the async module seems useful, but it seems like you would still have some level of API scripting on top.
Hi Michael,
I’d be quite interested in making sure the virt module is happy on Debian, though since it’s already using libvirt, I would expect that to be almost a no-op, if not already that.
I’m already using Ansible with Debian Squeeze and the virt module works like a charm.
I would be interested in seeing what this would look like, but I can’t say I’ll take it unless I like what it looks like.
Okay, at least that isn’t a ‘No’ 
Being able to invoke a virt-install command and wait for it with the async module seems useful, but it seems like you would still have some level of API scripting on top.
True, could be the case. I’ll try to implement a PoC and see how it goes.
Best regards,
Andreas Semt