add add_host action plugin - add hosts to inventory during a playbook #1491

Closed
wants to merge 1 commit into
from

Projects

None yet

2 participants

@skvidal
skvidal commented Oct 30, 2012
  • lets act on those hosts in the next play
@mpdehaan

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?

@mpdehaan mpdehaan closed this Oct 31, 2012
@skvidal
skvidal commented Oct 31, 2012

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" :)

@mpdehaan

To me, it feels weird to be in core.

I really want ansible to be about configuring hosts, but I'm still confused
a bit about it not looking like I want when it creates them.

There is a chicken-egg scenario there. It's designed for configuring
hosts, and the records in inventory are about hosts that exist. If you
are creating a host via a playbook, what writes it back such that it's in
there for later? Nothing, right now... and it seems improtant that it do
that.

It seems if you were to create a host using, say, Eucalyptus, and were
sourcing inventory from Eucalyptus, then the external inventory does all
you want -- and maybe, we just need that feature that allows us to use
multiple inventory sources -- files and scripts alike.

Thus this is why I'm drawn about ansible-provisoning in general. I am
thinking it is probably not a subproject, per say.

I kind of like knife's syntax for host creation -- yes, it helps you create
the host and makes it real, and then configures it, but it's not like you
are using Chef directly to describe the actual creation of the system,
you're using knife, and then it calls chef once the host is "real".

--Michael

@mpdehaan

Note, I'm still persuadable, but confused, but that is also easy this week :)

@skvidal
skvidal commented Oct 31, 2012

On Tue, 30 Oct 2012, Michael DeHaan wrote:

To me, it feels weird to be in core.

I really want ansible to be about configuring hosts, but I'm still confused
a bit about it not looking like I want when it creates them.

There is a chicken-egg scenario there. It's designed for configuring
hosts, and the records in inventory are about hosts that exist. If you
are creating a host via a playbook, what writes it back such that it's in
there for later? Nothing, right now... and it seems improtant that it do
that.

It seems if you were to create a host using, say, Eucalyptus, and were
sourcing inventory from Eucalyptus, then the external inventory does all
you want -- and maybe, we just need that feature that allows us to use
multiple inventory sources -- files and scripts alike.

Thus this is why I'm drawn about ansible-provisoning in general. I am
thinking it is probably not a subproject, per say.

I kind of like knife's syntax for host creation -- yes, it helps you create
the host and makes it real, and then configures it, but it's not like you
are using Chef directly to describe the actual creation of the system,
you're using knife, and then it calls chef once the host is "real".

So I can create the host all I want right now - and then run a playbook
against it. And I started to write the script to take 2 playbooks (create
and provision) and run them together. But I mentioned what I was doing in
the irc channel, Daniel mentioned the group_by action plugin and I went
from there. I agree that putting something in the inventory IF it is going
to be a permanent host matters.

But that's the whole point of this.

I have a profile of host (let's say builder). I want to launch a
generic-ish image of fedora17, get its ip, configure it up some and then
return the ip address to the user.

They get to use it - then the box goes 'boom' and is gone. If I want to
make the host persistent I give it a new ip, setup a playbook or group for
it w/that ip and ansible continues along merrily keeping the box current
and correct.

or maybe I'm misunderstanding your concerns.

-sv

@mpdehaan

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.

@skvidal
skvidal commented Oct 31, 2012

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?

@mpdehaan

Remember rocketship recovery? That's what I'm thinking about.

I don't remember rocketship recovery :)

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?

I am not saying anything about what ansible shouldn't do. I'm saying I
see gaps in this with how to persist hosts, and I think we're trying to fix
them piecemeal.

If I deploy a machine into a cloud, I think it's important to be able to
create a persistent record for it.

Right now we don't have a way to do that.

I also think it should be easy to spin up new nodes and then tell ansible
to configure them with a playbook.

This seems to be best done by output of provisioing tool into a temporary
inventory file mapping the groups, and then ansible launches against them.

If that tool existed, it could be decoupled by Ansible and used by a lot
more things too.

@robinro robinro pushed a commit to robinro/ansible that referenced this pull request Dec 9, 2016
@ovcharenko ovcharenko Bug report: ufw: interface option causes an error (1.9.4) (#1491) (#2668
)
bdf1a08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment