I'm not sure why this has to be "one tool"?
I just finished today rewriting my initially "homegrown" playbooks to
something integrated, starting from one allmost all covering main.yml.
That starts with provisioning cobbler, then creating a host (vmware here)
and pxe booting, with ansible. After that ansible continues regular
deployment.
Of course, we would like having more and better modules to cover that. Soon!
Serge
Yes, correct in that it’s not “one tool” with those other systems either.
Provisioning is all about low-level datacenter tasks, and in Cobbler’s case, it also helps you manage your DHCP and DNS (and power) if you so desire.
That way of describing hardware state versus Ansible’s way of describing policy I think deserve to be in multiple tools.
That being said, I can see something like Cobbler modules to manipulate system records (and do reinstalls) in our future. Cobbler system edit --name=foo coupled with a cobbler system restart is a pretty powerful way to reinstall things. Coupled with things like wait_for, you could bring up a bare metal cluster pretty easily
all in one clean pass, and get nice status/results along the way.
A lot of other people use different provisioning systems though, that is why we don’t pick just one.
The great thing about ansible here is there is really nothing to boostrap – an external inventory source is nice, but all you really want to do is make sure an SSH key is there – so it makes bare metal and cloud setups feel basically the same.