add add_host action plugin - add hosts to inventory during a playbook
run - lets act on those hosts in the next play
I am thinking we need a way to persist inventory to make this really workable.
Thus, it seems, we really have to make the inventory objects serializable.
This opens a whole other can of worms as we don't want to rewrite that file in place, and some of the inventory variables are also made available with group_vars/host_vars.
I am tentatively thinking that this doesn't become a core plugin for that reason. I WANT it to be, but we have to solve those problems first.
If you are using EC2/other as a remote inventory source, maybe all you need is a way to invalidate the cache from the inventory source?
So here's the thing - I don't want to permanently add to the inventory. I want to just add to the inventory for purposes of the in-memory playbook, nothing more. Is this still not acceptable?
maybe if I rename "add_temp_host" :)
Yeah I think I follow your point of usage.
I think I want to enforce that the hosts /do/ get added to inventory.
The way I would probably have done is it I would have a script that installs the new guest, fairly bare bones, not driven by an ansible playbook at all...
and then at the end of that it finishes with calling
ansible-playbook -i "192.168.10.50," playbook.yml
The idea of using ansible to drive the very top layer of provisioning is fine if people want to do it, but to me, perhaps based on whether I come from with Cobbler land and so forth, feels weird to me.
I see it as "provision -- then run ansible"
So, BYOP(provisioning) basically.
I also have this rather baseless though that I want to keep the module list in core /reasonably/ short, so if a module is to drop in core I want it to be something a really large amount of people are going to want to use, as there's a cognitive need to at least skim over all of them, and gut feel is this one is a little weird.
That all being said, I understand your use case. It just seems like it's an ansible-provisioning thing to me, and I am (off list) talking to dag a bit about possibly not making that part of the core project anyway. I just think it can be made a lot smoother and I'm not comfortable with ansible driving the top end of provisioning.
That being said, it clearly CAN do that, and I'm not going to stop that from happening either -- I just don't think I feel comfortable with that being the interface for how you describe how you create hosts.
okay - I am clearly confused.
How are you distinguishing creating a new instance and provisioning? What is it that you want to keep ansible separate from vs what cobbler does?
At this point I see ansible as primarily an orchestration tool. A way to perform a series of actions across multiple systems coordinating between them.
Remember rocketship recovery? That's what I'm thinking about.
I have 150 systems, I want to duplicate critical ones into the cloud in a single command. Some of them have persistent ips, some are just consumers and can have variable ips. But I do not want to set them up one by one.
I want to be able to write playbooks that describe setting up complete clusters of systems.
Which involves creating them, configuring them and dealing with their interconnectedness.
What part of that is something ansible should NOT do?