Running a local task in a playbook for remotes.

[Timothy Appnel]

I'm trying to write a playbook that needs to generate some files on the local  server Ansible is running and then go out to the remote doing things. I was under the impression that you could run something locally in a playbook and then perform tasks on the remote. I'm having trouble getting that to work. I'm using the latest devel branch as of earlier today.

playbooks/tpcreate.yml

---

- name: Test Local Run

  hosts: all

  user: tpettd

  vars:

    BASEPATH: /home/tpuser

  tasks:

  - name: Generate

    action: bin/ipcreate

    connection: local

  - name: Ping

    action: ping

$ bin/ansible-playbook -i ~/.ansible/inv.txt --private-key ~/.ssh/id_ansible --user tpuser playbooks/tpcreate.yml

PLAY [Test Local Run] *********************

SETUP PHASE *********************

ok: [hosta.example.com]

ok: [hostb.example.com]

TASK: [Generate] *********************

fatal: [hosta.example.com] => module bin/ipcreate not found in /data/ansible/library:playbooks/library

fatal: [hostb.example.com] => module bin/ipcreate not found in /data/ansible/library:playbooks/library

TASK: [Ping] *********************

no hosts matched or remaining

PLAY RECAP *********************

hosta.example.com : ok=1    changed=0    unreachable=1    failed=0                                       

hostb.example.com : ok=1    changed=0    unreachable=1    failed=0 

Clearly the Ansible is going out to the remotes instead of staying local. From what docs/examples there are on this its not clear what I am doing wrong. What am I missing?

Thanks.

<tim/>

-- 
Timothy Appnel

[CWS]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Your host is not set properly. From the documentation:

> To run an entire playbook locally, just set the “hosts:” line to
> “hosts:127.0.0.1” and then


What you will have to do is split the playbook into a local play and a
remote play, somewhat like this:

- ---

hosts: 127.0.0.1
tasks:
- - name: Some local task
action: some local task
connection: local

hosts: remote-group
tasks:
- - name: some remote task
action: some remote task

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQBN9IAAoJEH9Xbged0oyTXWQIAKTwl5cTLkiS+zFtjkHwj1Nd
htEAdglbQ+8wiObjP57o6d1uwF9NivMlSbVjo7dF2AJR/nHYK9CpanX/3Tt7wBFn
0vN/3JAYp47nT9kA4R/mfn/m9DVpIpvr1MNsUieVjJXNeOREN3kaTbOLiWteXkGc
jc27W0O2n3axKusM/jJdIP/PdhcUNaKCu5WQnINP6jXnqmxdG8qP9z7aL7jFsKKa
xtGRtVWN/0bjHrqOMp+UPH4RDA03Yjy3xPLunKWbLjmLEhRPn95cEpDWUMZtnCuh
CI3AiqIgKMt5oXT+Q7mBvv4MUlJAm6FuHC4p9PG+hwVVi60jVWf8TbPZhcQFsMU=
=/dSv
-----END PGP SIGNATURE-----

[Timothy Appnel]

Thanks Claus. Looking at the examples and docs it wasn't clear to me
that I could split the tasks like here. I'll give this a try when I
get in the office tomorrow. <tim/>

[Michael DeHaan]

Fixing some formatting errors in CWS's post, it looks like like this:

---

# ***** local configuration *****

- hosts: 127.0.0.1
connection: local



tasks:

- name: Some local task
action: some local task

# ***** now talk to some remote hosts ******

- hosts: remote-group

tasks:

- name: some remote task
action: some remote task

Also in Ansible 0.6 (devel), play books can import other play books, so you could split those into two files
if you want:


----
- include: local_play.yml
- include: remote_play.yml

[Timothy Appnel]

Things are working well. I had one minor quibble -- how to best say "all hosts except the local host?"

Put a conditional statement on all my remote tasks?

<tim/>

Sent from my iPhone

[Michael DeHaan]

You could put the host in a group called "localgroup" and then do:

hosts: all:!localgroup

Alternatively, put all of your other hosts in a group or groups and don't use "all", but use those groups instead.

(The INI format supports highly useful subgroups, it's a TODO to make the YAML format grok these)

[Timothy Appnel]

Nice. I love how Ansible is like a box of chocolates.

I missed that addition to 0.5 -- breezed right over it and didn't notice it. sigh.

As an aside, Is the INI format the general preference for inventory files given how YAML seems to trail it in terms of support?

<tim/>

Sent from my iPhone

[Michael DeHaan]

On Tuesday, July 17, 2012 at 5:46 PM, Timothy Appnel wrote:

Nice. I love how Ansible is like a box of chocolates.

I missed that addition to 0.5 -- breezed right over it and didn't notice it. sigh.

As an aside, Is the INI format the general preference for inventory files given how YAML seems to trail it in terms of support?

Warning:  complicated answer.   I want to discuss the present as well as the future.

I strongly prefer the INI format, except that the YAML format has a way to represent lists and hash data, for that need them in a host or group specific way.  I think this is a small minority of users, but a vocal minority who does in fact really need them.   It is definitely a mess how they don't have the same capabilities.

I have been thinking about how to eliminate YAML, and one way to do it might be for ansible to try to auto load certain files per group name and host name automatically, and let THESE files be YAML.

For instance, what if ansible ALWAYS tried to load variables in:

     /etc/ansible/vars/$inventory_hostname.yml   (the paths not actually just being /etc, but relative to the inventory file)

And also:

     /etc/ansible/vars/$group.yml  (for all possible group names)

If these files were not there, it would not load them, and it would be fine.    

Another option might be to just tell people HOW to do this as a pattern, but then you'd have to include that boilerplate in every play, which I don't like.

In this situation, we would no longer need to be able to store nested lists and hashes in the YAML inventory file, because of these implicit loads, you could easily move things to other files, and it would work basically like a vars_files line you'd never have to write yourself.

As a result, we could standardize on the INI format, and hopefully write a script to help people migrate.

I really want one format -- maintaining two parsers does not make sense with the goals of this project, and kinda runs counter to project goals of being minimal.   YAML was done as a great way to be able to represent structured data, but the fact that the groups are not strictly hierarchal, but YAML makes you build a tree (with relatively high levels of indentation) makes it a mess as a way of describing inventory.

This would have to be a two stage thing, we'd have to add this auto-load capability first, and ship that, and then write a conversion tool and deprecate YAML in a future release.

I don't want to leave anyone out in the cold though, and would refuse to do this without a migration tool.    However, since that tool could use the existing ansible API, it wouldn't be rocket science.

Thoughts?

[Michael DeHaan]

On Tuesday, July 17, 2012 at 6:16 PM, Michael DeHaan wrote:

On Tuesday, July 17, 2012 at 5:46 PM, Timothy Appnel wrote:

Nice. I love how Ansible is like a box of chocolates.

I missed that addition to 0.5 -- breezed right over it and didn't notice it. sigh.

As an aside, Is the INI format the general preference for inventory files given how YAML seems to trail it in terms of support?

Warning:  complicated answer.   I want to discuss the present as well as the future.

I strongly prefer the INI format, except that the YAML format has a way to represent lists and hash data, for that need them in a host or group specific way.  I think this is a small minority of users, but a vocal minority who does in fact really need them.   It is definitely a mess how they don't have the same capabilities.

I have been thinking about how to eliminate YAML, and one way to do it might be for ansible to try to auto load certain files per group name and host name automatically, and let THESE files be YAML.

Clarification:  I'm only discussing YAML inventory here, playbooks would remain YAML -- no plan in changing those.

--Michael

[Dag Wieers]

On Tue, 17 Jul 2012, Michael DeHaan wrote:

> On Tuesday, July 17, 2012 at 5:46 PM, Timothy Appnel wrote:
>
>> As an aside, Is the INI format the general preference for inventory files given how YAML seems to trail it in terms of support?
>
> Warning: complicated answer. I want to discuss the present as well as the future.
>
> I strongly prefer the INI format, except that the YAML format has a way
> to represent lists and hash data, for that need them in a host or group
> specific way. I think this is a small minority of users, but a vocal
> minority who does in fact really need them. It is definitely a mess
> how they don't have the same capabilities.

Why do you strongly prefer the INI format ? The original rationale was
that it is much cleaner for the simple case, but that's hardly true
today for more complex cases, where YAML is much more suited than the
INI format IMO.

Besides, YAML is used for playbooks, so people need to learn the format
anyway. Rather than making the INI format handle complex cases (which
it was not designed for) I think it's better to keep the INI format for
the very simple use-cases, and use YAML for the more complex use-cases.

So my counter-proposal would be to:

- Reduce the INI format to the simple use-cases (and document this limitation)
- Stop adding new capabilities to the INI format to keep it simple
- Add group of groups functionality to YAML syntax (which is the only missing part)

Another reason for keepin the YAML syntax is for executable inventories,
generating INI file output is considerably more complex than generating
YAML.

PS And what we definitely need is better syntax-checking and proper errors
for the YAML format. Try creating a YAML file without the obligatory ---
mark...

--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, in...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

[Michael DeHaan]

>
>
> Why do you strongly prefer the INI format ? The original rationale was
> that it is much cleaner for the simple case, but that's hardly true
> today for more complex cases, where YAML is much more suited than the
> INI format IMO.

With all the different ways to add groups and hosts and children we have now in YAML (and would have to add subgroups!), it's basically impossible to tell what sort of configuration you really have now, and the sea of variables intermixed in with the host definitions makes it worse.

For playbooks, we use YAML because they are very limited in terms of structure, and many people will only barely need to understand it is YAML. I didn't pick that because it was YAML, I did that because it kept me from having to write a parser
and it was good enough.

>
> Another reason for keepin the YAML syntax is for executable inventories,
> generating INI file output is considerably more complex than generating
> YAML.

Not necessary -- That's what the external inventory script is for, you don't have to code generate them when you are using an external data source.

Further, there is nothing saying we can't let the inventory API self-serialize from the Python API.

If you really like YAML, the YAML support could be implemented in terms of an external inventory script, which is, now that I'm thinking of it, probably exactly how we're going to offer migration.

>
> PS And what we definitely need is better syntax-checking and proper errors
> for the YAML format. Try creating a YAML file without the obligatory ---
> mark...

This is exactly why YAML is bad for complicated documents.

It will be ok, and this is going to happen.

(If we do the external inventory YAML reader, it's going to be super painless and you'll be able to keep on going. I think I like that better than the migration script, even, and starts people down the path that I think was very successful for puppet with external nodes -- if you do not like our storage format, you can easily write your own. That was exactly the idea in doing it this way in Ansible, too)

--Michael

[Timothy Appnel]

I don't see YAML being that bad, but I don't feel strongly enough to push the issue.

I do think there should be one format. If that format is an INI file it should be purposely limited in what it can represent. Complex cases that need to implement an inventory script or system .