Thinking of something…
Generally if I’m using play books for classical config management, I want the host groups all entered in, and I’ll run ansible periodically to reapply my configuration. Though, as Seth mentioned, one of the likely use cases is Cloud Deployment. (and he’s also brought this up before WRT /usr/bin/ansible)
In that case, I have some new nodes that (some random tool or API has just spun up), and I might just want to bootstrap it. In this case, I might want to not specify (or at least override) the hosts in my play books, and even avoid the hosts file. Why? Say I’ve brought up a new xyz.example.org in vmware, and I am really going to be want to install some 3rd party management software on it with ansible. And I’m doing this FROM some other larger management application that is making use of Ansible.
Possible syntax:
ansible-playbook bootstrap.yml --force-host hostname.example.org
(also doable via Python API)
This would make all the host patterns in the file default to exactly that host (the host pattern wouldn’t even need to be in the file), and ignore the inventory file.
The sort of reasoning here is that play books are not just for config management, they can also be for basic deployment, so the idea of bootstrapping your management software from a pristine image using Ansible might be compelling.
In other words, if you have some application that can create VMs, or deploy VMs, and you have to inject software into those VMs once they are running, Ansible is really an ideal way to do it.
Thoughts?
–Michael
(BTW – Ansible has had a tremendous weekend on Reddit!)
I think this is a good use case. For the model I was working on my plan
was to do it from the python api and couple it with libcloud. So you
could do something like:
start_cloud_instance -k mysshkey -cec2 -i fedora16-x86-64 \
-m playbook.yml
which would start it up at whatever cloud service you're using, get the
ip from the libcloud api to start up the instance, then connect with
ansible (via the api) and set up the instance.
-sv
I think this is a good use case. For the model I was working on my plan
was to do it from the python api and couple it with libcloud. So you
could do something like:
start_cloud_instance -k mysshkey -cec2 -i fedora16-x86-64
-m playbook.yml
which would start it up at whatever cloud service you’re using, get the
ip from the libcloud api to start up the instance, then connect with
ansible (via the api) and set up the instance.
-sv
That sounds great.
Yeah, so as long as we can push in the host list as an API parameter, we should be good to go.
IIRC, this already works if you pass in host list an array versus a string (where it is treated as a path), so I probably just need to expose this on the CLI to make it easy for that.
The other thing I need to do is make sure that for plays in the playbooks, if the host pattern is NOT listed, it defaults to “all”, so that everything “just works”.
Incidentally I added some unit tests for the playbook in “tests/” just recently, that should illustrate using arbitrary callbacks to the Playbook lib. It keeps track of a list of expected “events” so we can pretty rapidly tell if something regresses in playbook land. I have to add some additional tests for imports and vars_files so we have better coverage, but it’s coming along.
Playbooks still need some error handling upgrades if something is grossly miskeyed or things are left out, but I think they are working pretty good now and I’m improving error reporting when I find things.
I should reinstate the host summary at the end of the process (how many hosts had how many changes) and probably see about how to include a bit more output about what a host says beyond just “ok”. However, it’s a bit noisy to just dump everything from the command output – still, using the callbacks class, the caller gets to choose.
–Michael
I have a todo list item for myself to attempt to port one of the fedora
infra host setups over to a playbook to see how much of a giant ass
pain it would be to do.
-sv