Variables defined in vars is available to included playbooks but variables
included via vars_files is not.
Files to reproduce - https://github.com/j-manu/debug/tree/master/ansible
Run command ansible-playbook -i inventory site.yml
--
You received this message because you are subscribed to
Variables defined in vars is available to included playbooks but variables
included via vars_files is not.
Files to reproduce - https://github.com/j-manu/debug/tree/master/ansible
Run command ansible-playbook -i inventory site.yml
--
You received this message because you are subscribed to
Hello,
I am trying to write my own callback function which logs information which
I want to database, especially informations from local facts.
We have localfacts in json mode and I can easly get access to them from
Ansbile it self, however everything what I've tried in terms access them
from
And still have question.
Is there any way to use facts_get with DICT?
For example:
facts.get('ansible_local[apache]) ???
or
facts.get('ansible_interfaces[eth].some_argument) ???
Best regards,
Marcin Praczko
--
You received this message because you are subscribed to the Google Groups
I would recommend using a dynamic inventory script that would provide the
information, assuming it can be found via some local command or API?
On Mon, May 12, 2014 at 6:15 PM, Noah Parker neat...@gmail.com wrote:
Hello,
The way I am implementing Ansible will mean that I will not know the IP
you always need inventory, but you can do it int he command line:
-i '192.168.1.24,'
the comma is required as it signifies its a list vs a directory/file
--
You received this message because you are subscribed to the Google Groups
Ansible Project group.
To unsubscribe from this group and
On Saturday, 1 March 2014 08:58:47 UTC, Michael Mahemoff wrote:
http doesn't work stderr: gpg: no valid OpenPGP data found.
Did you ever resolve this Michael? Just hit the same OpenPGP error with
MariaDB...
--
You received this message because you are subscribed to the Google Groups
There's a degree of fuzzy logic in the synch module to understand
localness, but it's not perfect --- it was actually pretty surprising how
complex guessing the right params to sync needed to be.
To understand this further though, can we please see the lines from your
playbook that you are using?
But looks like the variable file is referred to, before the
variable inventory_file is loaded?
I'm not sure what this means, can you elaborate?
Thanks!
On Mon, May 12, 2014 at 3:27 PM, Mridusmita Talukdar mridu...@gmail.comwrote:
Hi,
We have multiple clusters. Each of the clusters need to
Not sure what is going on with pip in your case, but there's nothing in
Ansible's pip configuration that running it 8 vs 9 times would change :)
Ansible 1.4 is quite old though and there have been security updates in the
1.5 series, you should take the time to fix variable issues for sure so you
Exciting!
On Tue, May 13, 2014 at 12:20 AM, Dmitry Makovey droopy4...@gmail.comwrote:
For posterity: I've tracked down the issue - it was FreeBSD's UFS
Journaling that was crashing things. Looks like ansible was able to
thrash system well enough to expose issues with that FS feature. After
Please file a ticket at github.com/ansible/ansible.
Thank you!
On Tue, May 13, 2014 at 2:37 AM, Manu J manu.1...@gmail.com wrote:
Variables defined in vars is available to included playbooks but variables
included via vars_files is not.
Files to reproduce -
Hi!
This is really a question for ansible-devel, since this is about developing
code that uses the API. Can you post there?
Thanks!
On Tue, May 13, 2014 at 7:14 AM, Marcin Prączko marcin.prac...@gmail.comwrote:
And still have question.
Is there any way to use facts_get with DICT?
For
And we should never teach people that trick, because it's quite useful to
have inventory.
It's kept around for historical reasons but may not be there indefinitely.
On Tue, May 13, 2014 at 8:38 AM, Brian Coca brianc...@gmail.com wrote:
you always need inventory, but you can do it int he
Hello,
Running this test playbook, I have the following error:
- hosts: localhost
tasks:
- name: Test IP address
debug: msg=ok
when: {{ ansible_lo.ipv4.address }} == 127.0.0.1
[WARNING]: It is unneccessary to use '{{' in conditionals, leave variables
in
loop expressions bare.
You when line need to be manipulated just a bit to look like:
when: ansible_lo.ipv4.address == 127.0.0.1
You don't need {{}} in a when statement, you don't need to quote the whole line
and you need to individually quote the IP address.
--
Matt Martz
m...@sivel.net
On May 13, 2014 at 11:17:24
On 05/13/14 18:36, Michael DeHaan wrote:
There's a degree of fuzzy logic in the synch module to understand
localness, but it's not perfect --- it was actually pretty surprising
how complex guessing the right params to sync needed to be.
To understand this further though, can we please see the
I have a playbook that sets up the application configuration on a
server in a cluster. This configuration is based on other servers in
the cluster and uses hostvars to great effect in the templated
configuration. I'm really happy at how easy ansible make that. To make
that work so that the facts
How do you always have a set of tasks run regardless of the tag being passed in
on the command line?
I'm getting to the point where I have a 'core' playbook that must be run before
any other playbook I have. This does specific things such as set specific
facts based upon my local environments
You're getting an error because both the left and right value need to be
quoted due to the extra template evaluation you had requested, which is why
Ansible is giving the warning about this.
This is simplified if you leave off the unneccessary {{ foo }} and just say
foo.
On Tue, May 13, 2014 at
Besides the above, another issue is whether it is good default behavior to
connect to localhost through ssh if 'ansible_connection' is undefined
It depends if localhost is in inventory or not, but there is nothing to
presume an explicit entry of localhost has requested a particular way to
This has come up once or twice.
When limiting, you can't get facts from other hosts.
The solution is to not use --limit and instead do:
hosts: mygroup:{{ limit_spec }}
and pass -e limit_spec=what_I_would_have_passed_to_limit
This allows patterns like:
- hosts: all
tasks: [] # gather facts
You should be tagging such tasks with something like 'core' like you say
above, for now.
We would entertain an 'all' tag if well implemented, which I believe we've
also said before.
So what should I be doing here?
Submitting a pull request? :)
On Tue, May 13, 2014 at 3:49 PM, Snyder,
I believe there is a pull request for an all tag at
https://github.com/ansible/ansible/pull/7039
On Tue, May 13, 2014 at 12:53 PM, Michael DeHaan mich...@ansible.comwrote:
You should be tagging such tasks with something like 'core' like you say
above, for now.
We would entertain an 'all'
Thanks for the additional options. But doesn't it seem weird that you
should/shouldn't use --limit based on the implementation details of
the playbook? Should the person who is running the playing have to
know about the inner workings of the playbook file in order to know
whether to use --limit or
Good deal.
This is marked a P3 ticket, so it's in queue once we get the P2's smited
down properly not too far away, hopefully!
On Tue, May 13, 2014 at 4:35 PM, Peter Gehres
peter.geh...@appdynamics.comwrote:
I believe there is a pull request for an all tag at
But doesn't it seem weird that you
should/shouldn't use --limit based on the implementation details of
the playbook?
Depends what you want limit to do. It's kind of a damned if you do/don't,
sort of thing.
I suppose we could make a smart exemption for a single play with no tasks
other than
Yeah... I'm confused. I found with_nested to be a bit odd in the first
place, much less trying to figure out what Petros is adding.
I ended up with
https://github.com/jerrac/aspects/blob/master/ansible_plugins/lookup_plugins/subdict.pyused
at
If I run something like:
$ ansible -a [ -d my_app ] chdir=/run/uwsgi/app ec2
Even with max verbosity, this doesn't seem to output the raw JSON output.
However if I do, e.g. :
- command: [ -d uwsgi_dev ] chdir=/run/uwsgi/app
register: result
- debug: var=result
Then I get the full JSON
Hi,
this
when: item.mount != /
does unfortunatly no do what it is supposed to do. The condition fails even
though item.mount contains a /.
For explanation: item.mount is derived from ansible_mounts and describes
the root partition.
Any help appreciated.
Thanks in advance.
--
You received
30 matches
Mail list logo
