a play is a host to task mapping, roles are a group of tasks, as long
as they are in the same hosts mapping they are in the same play:
- hosts: all
roles:
- role1
- role2
you can have additional plays in the same file or execute several
files in the same invocation, both of these are
ad hoc commands do not gather facts, which is what sets
ansible_hostname, this is an expected result
--
Brian Coca
--
You received this message because you are subscribed to the Google Groups
Ansible Project group.
To unsubscribe from this group and stop receiving emails from it, send an
Oops,
I really should learn to read digits, so it's going up from less than
1second to 44 seconds. Do you run this from the same machine?
Am 03.12.2014 14:03 schrieb Mirko Friedenhagen mfriedenha...@gmail.com:
Brent,
in your gist the realtime seems to have actually _decreased_ from 46 to 44
Ouch, I don't even know how to concatenate plays automatically, so I'll
have to do some homework. Thanks!
--
You received this message because you are subscribed to the Google Groups
Ansible Project group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Removing the code that lets you know when there's a syntax error seems to
be a bad thing :)
not sure what's up there to be honest, but I think pinning down what the
error is is appropriate.
On Wed, Dec 3, 2014 at 10:50 AM, simonq si...@qubs.se wrote:
Sorry for the late reply, forgot about
Please let us know if you observe problems in 1.8.X -- we won't be doing
backports to an older series, though I suppose you could if you really
wanted to, we can't support older versions on this list.
On Tue, Dec 2, 2014 at 9:18 PM, Alex King a...@king.net.nz wrote:
Indeed it runs _much_
I am writing facts on my targets that I want to collect using ansible. In this
example, I have a facts.d/prefs.fact and a facts.d/java.fact. I can see this
works:
# ansible tomcat_servers -i inventory -m setup -a 'filter=ansible_local'
tomcat02 | success {
ansible_facts: {
Nevermind, this is indeed ansible_hostname, which is not available because
it's a fact -- sorry!
On Wed, Dec 3, 2014 at 11:15 AM, Michael DeHaan mich...@ansible.com wrote:
Sounds like he's discussing a variable in his inventory file and not a
fact, though.
However, it's more apt to say
Filtering isn't very deep, but that's not really the point of the feature.
Basically the filter is there for humans doing browsing, not the API or
scripts.
In templates, you would just access the variable as normal.
{{ ansible_local.java.JAVA_HOME }}
or equivalently:
{{
According to the Ansible docs (
http://docs.ansible.com/faq.html#how-do-i-loop-over-a-list-of-hosts-in-a-group-inside-of-a-template
) You can put the following in a template:
{% for host in groups[’test_servers'] %}
{{ hostvars[host]['ansible_eth0']['ipv4']['address'] }}
{% endfor %}
But
I totally understand and agree, but I am a human doing browsing.
I figured it out using *jq *(you need *sed *to cut out the tomcat02 |
success portion before the first '{'):
# ansible tomcat_servers -i inventory -m setup -a 'filter=ansible_local' | sed
's/.* //' | jq -r '.[][][java]'
{
I had a helpful answer for that:
ansible server -m setup -i production, should provide you the correct
info.
I suspect one of your hosts does not have an ipv4 address assigned to
eth1.
I added a condition:
{% if hostvars[host]['ansible_eth1']['active'] %}
(replace eth1 by eth0 in your case)
Hello all,
I have a rather complicated playbook which orchestrates the following
plays: *(a)* input validation (extra-vars w/ asserts), *(b)* launching an
EC2 instance, *(c)* configuring the instance, *(d)* fact gathering, *(e)*
building and tagging an AMI from the instance, *(f)* using the
So after putting some effort fixing the problem and doing some googling
which led me to this thread
https://www.mail-archive.com/ansible-project@googlegroups.com/msg07926.html I
got it to work with the latest version.
Solution: change* '{% raw %}{{ .Image }}{% endraw %}' *to *\{\{.Image\}\}*
no, registered variables are not facts, you can use the template
module to create a local fact in /etc/ansible/facts.d/ and trigger
fact gathering again.
On Wed, Dec 3, 2014 at 1:27 PM, Robb Wagoner robb.wago...@gmail.com wrote:
Hello all,
I have a rather complicated playbook which
Are there plans on supporting the kerbros authentication so this works in
domain environments?
On Friday, October 17, 2014 11:02:06 AM UTC-4, Bryan Cochrane wrote:
I am trying to setup windows remoting for ansible.
I have Ansible version 1.7.2, ee-bryan is Windows 8.1, ee-csg is Windows
Following up on this, it looks like that server had a pretty old version of
ec2.py as the inventory script. When I replaced it with the currently
linked one from github, it behaved much better:
# time ansible tag_environment_development -m ping --list-hosts
10.10.5.157
10.10.4.221
Is it possible to provision EC2 instances with multiple interfaces? From
reading the docs, there is no indication that this is possible, and from
the code[1], it looks like it is not possible, but I figured I should ask
in case I am missing something.
[1]:
a few bugs with variables were present in 1.8.x, could you test with
current devel as there are fixes there (soon to be released) that
might solve your issue.
On Wed, Dec 3, 2014 at 4:31 PM, Ross Becker ross.bec...@gmail.com wrote:
So, I have a batch of playbooks that include tasks where the
Ahah- yes, it works again when I tested ansible at current git state. OK,
I'll make sure that we're pegging our ansible version to 1.7.2 for the
moment, and wait for the next release to pull that back out. Thanks!
On Wednesday, December 3, 2014 1:38:48 PM UTC-8, Brian Coca wrote:
a few bugs
Also I'd double check that those two vars in the include do not come from
facts or inventory.
(That would have been any any-version thing)
On Wed, Dec 3, 2014 at 4:38 PM, Brian Coca bc...@ansible.com wrote:
a few bugs with variables were present in 1.8.x, could you test with
current devel as
Thanks!
On Tuesday, 25 November 2014 13:02:20 UTC-8, Brian Coca wrote:
check this setting, I believe it will allow you to do what you want
http://docs.ansible.com/playbooks_delegation.html#maximum-failure-percentage
--
Brian Coca
--
You received this message because you are
Yeah I think I remember the template commit.
(But it's not going to gather facts first, because facts are a playbook
concept)
The v2/ tree effort is essentially going to make in memory playbooks for
ad hoc commands so might make this easy with a --gather-facts switch in the
future or something
Role variables are definitely a thing.
Where you can move top level playbook things to vars/ or defaults/ in a
role it can be a good idea.
Simple playbooks like fix shellshock could use vars or vars_files fine,
or even if you find other uses, that's fine too.
We're not particularly dogmatic
Hi,
It seems common practice for playbooks to have a hosts file in the root
of the playbook.
When you run a playbook you have to supply it via the -i parameter,
otherwise you will get the error: ERROR: Unable to find an inventory file,
specify one with -i ?
It would be nice if Ansible would
I think explicitly passing in the inventory is OK: pretty soon you'll have at
least two of them (staging/prod etc.), and you REALLY don't want to apply
changes to the wrong set of hosts ;-)
If you still want to set a default inventory path, you can do this through
ANSIBLE_HOSTS environment
26 matches
Mail list logo
