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
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
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/>
Fixing some formatting errors in CWS's post, it looks like like this:
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/>
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)
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/>
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?
Clarification: I’m only discussing YAML inventory here, playbooks would remain YAML – no plan in changing those.
–Michael
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...
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
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 .
<tim/>