On 2 Dec 2014, at 23:33, Brian Coca wrote:
> try this:
>
> - debug: var=ansible_eth0
Sorry, that doesn’t work:
fatal: [test.example.com] => {'msg': "One or more undefined variables: 'dict
object' has no attribute 'ansible_eth0'", 'failed': True}
GTG
--
Gordon Ross
--
You received this mes
Thanks - I'm somewhat confused about the terminology now. I have a single
playbook with multiple roles. Is this all considered the same play? It's
certainly all executed within a single run of ansible-playbook.
I can access the registered vars from the same *role* in the playbook, but
not from ano
On Tue, Dec 2, 2014 at 12:39 AM, Marc Roelofs wrote:
> Hi All,
>
> I am experiencing something weird.
> I have a couple of template files I need to copy over to different CentOS
> versions.
> The task is simple :
> # copy file
> - name: copy my-files
> template: src={{ item }} dest=/etc/my-dest
Yes, those are stored in the variable cache globally, and should be
accessible within the same play from any other task.
On Tue, Dec 2, 2014 at 10:40 PM, Ananda Debnath
wrote:
> From what I'm hearing I should be able to directly access registered
> vars/set_fact facts onwards from where I declar
Oh sorry, I didn't mean to push the discussion onto the ticket - just
pointing out that it exists so other people are interested in it. Mailing
lists are often better than tickets for discussing how we want things to
behave. Then we can use the ticket to hammer out implementation of that
behavio
>From what I'm hearing I should be able to directly access registered
vars/set_fact facts onwards from where I declare and define it regardless
of the play I'm in... correct?
On Monday, December 1, 2014 11:56:45 PM UTC-6, Ananda Debnath wrote:
>
> Thanks James.
>
> I understand the recommendatio
Check the gist. I left an example of the timing difference.
On Dec 2, 2014 7:01 PM, "Michael DeHaan" wrote:
> Inventory gets processed on startup time a bit more now -- that's good for
> various reasons as it would do it later anyway and that data can be needed
> -- but I'm curious if you could
Indeed it runs _much_ faster with host_key_checking disabled.
I have a dynamic inventory - I written a script to produces the groups,
hosts and hostvars.
I'm on ansible 1.7.2+dfsg-2, the version in Debian testing and destined for
Debian stable release in the next few months. I'm happy to test
Thanks for the pointer to that issue. I'll move the discussion there.
On Wednesday, 3 December 2014 12:15:28 UTC+11, tkuratomi wrote:
>
> I don't know the proper answer to your question, the docs definitely
> could be interpreted either way right now. And there does seem to be
> a use case for
I don't know the proper answer to your question, the docs definitely
could be interpreted either way right now. And there does seem to be
a use case for update=no not doing an initial clone but you're not the
first person to request update=no to do an initial clone:
https://github.com/ansible/ans
If I understand you to mean "ad hoc remote command" then yes. If you
mean to "any of the ansible modules" then no.
Things you can do:
ansible server -a 'chdir=/opt/ pwd'
ansible server -m shell 'cd /opt/; pwd'
Things you can't do:
ansible server -m git -a 'cd /opt/ ; dest=./in/opt'
Note: w
If the libraries we're using support it I think that modifying
attributes makes sense. There's many other modules which allow
modification of attributes. Care to submit a pull request for that?
-Toshio
On Tue, Dec 2, 2014 at 7:14 AM, Dan Vaida wrote:
> Unfortunately, the ec2 module (neither of
On Tue, Dec 2, 2014 at 7:30 AM, Dan Vaida wrote:
> Hello everyone,
>
> I'm just trying to do some cleaning up as part of my playbooks and one task
> should go around and remove dummy security group(s).
> Because of this case, I don't see the utility of the 'description' parameter
> as being mandat
should already be there in fact :)
On Tue, Dec 2, 2014 at 7:02 PM, Michael DeHaan wrote:
> yeah, please do not jump to that conclusion
>
> Due to a PPA upload error, it was never pushed to begin with. This is a
> correctable thing.
>
>
>
> On Tue, Dec 2, 2014 at 11:38 AM, Scott Miller
> wrote
yeah, please do not jump to that conclusion
Due to a PPA upload error, it was never pushed to begin with. This is a
correctable thing.
On Tue, Dec 2, 2014 at 11:38 AM, Scott Miller
wrote:
> Is there a confirmation that this was removed from the PPA intentionally?
>
> On Thursday, November 2
Inventory gets processed on startup time a bit more now -- that's good for
various reasons as it would do it later anyway and that data can be needed
-- but I'm curious if you could provide info about what "much longer"
means? Such as before and after numbers, and numbers of hosts in your
invento
Yep -- docs may have not been pushed quite yet, we do that periodically.
On Tue, Dec 2, 2014 at 6:51 PM, Toshio Kuratomi
wrote:
> Thanks for pointing this oout! Looks like jimi-c merged a doc fix for
> that a little while ago.
>
> -Toshio
>
> On Mon, Dec 1, 2014 at 6:45 PM, Marc Trudel wrote:
Thanks for pointing this oout! Looks like jimi-c merged a doc fix for
that a little while ago.
-Toshio
On Mon, Dec 1, 2014 at 6:45 PM, Marc Trudel wrote:
> https://github.com/ansible/ansible/issues/9678#issuecomment-65175648
>
> Essentially, the documentation still mentions "baby JSON", whereas
I don't know about vargrant, but there should be no issues in setting
a variable per host with the version using set_fact.
--
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 email
Hi guys,
I'm hoping I've just overlooked an option, but here's the situation:
After updating from ansible 1.6.2 to 1.8.1, I noticed our ansible runs take
much much longer to actually make contact with the servers. Here is a
really simple comparison:
https://gist.github.com/brentley/7c644614e5dc
try this:
- debug: var=ansible_eth0
--
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 email
to ansible-project+unsubscr...@googlegroups.com.
To post to
Hello, maybe you can help me with little query.
I have virtual lab based on vagrant and ansible.
All vms should be with same app installed but with different version
number.
What's the correct way to configure ansible to install a range of versions
and keep vagrant know this version (for unde
Is there a confirmation that this was removed from the PPA intentionally?
On Thursday, November 27, 2014 7:42:02 AM UTC-5, Mehul Ved wrote:
>
> On Thu, Nov 27, 2014 at 4:35 PM, Tomas Karasek > wrote:
> > Hi, I don't see 1.8.1 (nor 1.8) in the ppa:
> > https://launchpad.net/~ansible/+archive/ubu
I’m running Ansible 1.4.4 which comes with Ubuntu 12.04 LTS. I’m getting weird
results when trying to get host facts.
If I have:
- debug: var=hostvars[inventory_hostname]
I get the all the information I’d expect, including:
ok: [test.example.com] => {
"hostvars[inventory_hostname]": {
…
"an
:) Too late... already voted :P
On Tuesday, December 2, 2014 3:59:18 PM UTC+2, Michael DeHaan wrote:
>
> We're planning on getting a 1.8.2 out to correct for this packaging item
> and a few others today or early tomorrow.
>
> But there is no voting. Seriously. There isn't any voting :)
>
>
>
>
MM> The problem is that cannot nest jinja brackets inside of brackets.
Ah! Right, because brackets mean "Jinja", not just "variable". Still new
here. :^)
MM> Your following example:
MM>
MM> {{ ansible_hostname | regex_replace("^{{service}}-{{site}}-", '') }}
MM>
MM> Should probably be:
MM>
MM>
The problem is that cannot nest jinja brackets inside of brackets. Your
following example:
{{ ansible_hostname | regex_replace("^{{service}}-{{site}}-", '') }}
Should probably be:
{{ ansible_hostname | regex_replace("^" + service + "-" + site + "-", '')
}}
Inside of {{ }} variables are alr
I have some variables like 'service', which can be "abc" or "xyz", and
'site', which can be "bos" or "sfo", on different hosts. I have hosts
whose FQDNs are like service-site-thing-N.site.service.care.com, which
have those those variables set accordingly, in a group like 'things'.
My use case is t
changed_when: False
On Tue, Dec 2, 2014 at 12:10 AM, Yvo van Beek wrote:
> With regards to point 5, I noticed that Ansible 1.8.1 no longer reports
> "creates=" as "skipped". So that's great. Is there an option we can use to
> report "when:" as "ok" too?
>
> --
> You received this message becau
Thomasz nice, but what does the syntax look like :)?
--
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 ansible-project+unsubscr...@googlegroups.com.
To post to
Hello everyone,
I'm just trying to do some cleaning up as part of my playbooks and one task
should go around and remove dummy security group(s).
Because of this case, I don't see the utility of the 'description'
parameter as being mandatory.
One step further, I'd rather see the module support s
Unfortunately, the ec2 module (neither of the AWS related modules for that
matter) doesn't allow you modify the attributes of an EC2 instance (i.e.
change its security group). I'd go as far as actually submitting this as a
feature suggestion if more agree on that.
By following the steps in the
On 2 December 2014 at 14:59, Michael DeHaan wrote:
> But there is no voting. Seriously. There isn't any voting :)
+1
--
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, s
We're planning on getting a 1.8.2 out to correct for this packaging item
and a few others today or early tomorrow.
But there is no voting. Seriously. There isn't any voting :)
On Tue, Dec 2, 2014 at 6:56 AM, Ivaylo Bratoev
wrote:
> I vote for 1.8.2 release mostly because of this issue:
> h
I vote for 1.8.2 release mostly because of this
issue: https://github.com/ansible/ansible/pull/9660 . Currently, the 1.8.1
is almost unusable targeting Windows hosts.
On Saturday, November 29, 2014 12:40:17 AM UTC+2, Mirko Friedenhagen wrote:
>
> Hello Michael,
>
> yes, homebrew normally checks
Hi,
Is it possible to pass chdir directive to ad-hoc module?
I would like to do something like that;
ansible server -a 'cd /opt/; java -jar export.jar ' [WRONG, don't use it]
ansible server -a 'java -jar export.jar' -e chdir=/opt/' [WRONG, don't use
it]
--
You received this message because you
Hello,
I am seeing this kind of flakiness as well on Debian Wheezy. Every other
execution of a playbook will result in copy actions marked as changed (not
even template, just copy). Same with lineinfile.
Regards
Mirko
--
Sent from my mobile
On Dec 2, 2014 9:39 AM, "Marc Roelofs" wrote:
> Hi Al
Hi All,
I am experiencing something weird.
I have a couple of template files I need to copy over to different CentOS
versions.
The task is simple :
# copy file
- name: copy my-files
template: src={{ item }} dest=/etc/my-destination/
with_items:
- file1
- file3
- file3
- file4
-
Hi,
I would like to get some clarification on the intention of update option in
git module.
My original understanding:
- when update=yes, then repo will be cloned once and then updated via git
pull every time
- when update=no, then repo will be cloned once but would never be updated
with git p
39 matches
Mail list logo
