Hello all,
some time ago I wanted to run quite lengthy playbook on several (over 100
...) nodes. These nodes are not really similar so I wasn't surprised that
on many of them
this particular playbook failed (to make it worst: it failed on different
tasks ...). So at the end I was left with
Just tried the latest dev release with the exact same result. So it still
doesn't seem to be working.
Am Donnerstag, 2. Januar 2014 21:10:46 UTC+1 schrieb James Tanner:
Please retest against devel/HEAD. There have been a few refactors of
authorized_key since the 1.4.x releases.
On Jan 2,
at the end or the run of the playbook reporting you should see a line
similar to this
--limit @/playbook/running/dir /playbookname.retry
you can add it to your command line you used to run and that will run on
the failed hosts, check your output and check the file referenced their
On 3 January
Yes, to clarify, possible bug with sudo being used when I don't expect it.
I deleted everything but the code needed to demonstrate the (possible) bug.
That code, when run - as is, demonstrates the problem.
It is part of a larger effort to create an Ansible config to provision a
Vagrant box,
I think after 1.2, as far as i know if a host fails a task it will be added
into the file. If you want the new run to start at specific task that is
doable by the extra option start at task
On Jan 3, 2014 12:03 PM, przemol p@cmcmarkets.com wrote:
Last time I checked it was referring just to
Really great and much easier (for me) to browse the doc ! !
thanks for that !
2014/1/3 Michael DeHaan mich...@ansibleworks.com
Just a few new things today, all unrelated :)
(A)
Of interest to most:
http://ansibleworks.com/docs/ now redirects to our new docsite, which is
hosted at
The module is required where the task is being run, which is likely the
remote host.
There is no exception.
Yep, this is what I'd expect too! that means we are catching the error and
presenting you a human readable warning instead of a traceback.
On Fri, Jan 3, 2014 at 2:45 AM, nORKy
Please make sure there's a github ticket that includes steps to reproduce.
This may require sharing a sanitized version of your authorized key file as
well as what keys you are adding, or steps from your playbook.
On Fri, Jan 3, 2014 at 3:24 AM, Jürgen Haas juer...@paragon-es.de wrote:
Just
That code, when run - as is, demonstrates the problem.
That's not what I wanted, I set sudo = no in the docker.yml.
There's no variable called sudo you can just drop in a YAML file, which
implies we need to see the full uncensored playbook to tell you what would
need to be changed.
Can you
I'm fine with making the scp_if_ssh controllable via a per-group or
per-host inventory variable, such as ansible_scp_if_ssh as we have with
control over SSH ports, sudo users, and other things.
That probably seems best in your case.
I would suggest to either open a github ticket for the feature
ok, so the module is installed on my remote host.
How can I have the traceback ? The module works manually not with ansible.
Le vendredi 3 janvier 2014 13:57:28 UTC+1, Michael DeHaan a écrit :
The module is required where the task is being run, which is likely the
remote host.
There is no
You don't want the traceback, proper error handling is better.
Please show the steps you have taken to have the module installed on the
remote host, and the snippet of your playbook that uses it.
On Fri, Jan 3, 2014 at 8:19 AM, nORKy joff...@gmail.com wrote:
ok, so the module is installed
ansible_env gets set when facts are gathered and of course user variables
depend on which user was used to gather those facts.
--
Brian Coca
Stultorum infinitus est numerus
Yes. Well surmised. Is there any way to re-trigger the gathering inside a
playbook?
On 3 Jan 2014, at 14:55, Brian Coca brianc...@gmail.com wrote:
ansible_env gets set when facts are gathered and of course user variables
depend on which user was used to gather those facts.
--
Brian
I think this has been answered in a previous post.
https://groups.google.com/forum/#!searchin/ansible-project/$20facts$20gathered/ansible-project/AGuHOnCgpc4/XIKaAnP3I-UJ
re-run the setup module, to get updated ansible_env
tasks:
- action: setup
Thanks guys!
On Friday, January 3, 2014
Please excuse my replying to myself: some amendments, and the results of
additional searching.
On 03/01/14 16:34, Nick wrote:
- If so, can I create list elements?
This post suggests not:
https://groups.google.com/d/msg/ansible-project/cPbCD6R9TnE/-6StqLZjKX0J
But that it may be added later?
Hi,
so far facts and registered variables are preserved only thru playbook. Do
not be confused by several plays - one playbook may and have several
plays every so often.
David
2014/1/3 Nick oinksoc...@letterboxes.org
Please excuse my replying to myself: some amendments, and the results of
Pip 1.5, released on 1/1/2014, doesn't support --use-mirrors. The default
should be use_mirrors=no, as this should work correctly with all versions.
I ran into the issue where we use Ansible to easy_install pip and then use
pip to install python libraries.
I created a pull request:
Changing the default seems like an bad design choice as it may break
existing users.
Question:
(A) if they are removing the option, does it *ALWAYS* use mirrors then?
(B) can we test the pip version and then raise an error if the option is
used in a way it cannot support?
On Fri, Jan 3,
I use group_by to set up some groups in a play, but it looks like this
doesn't automatically load anything i have in group_vars for those new
groups. I suspect group_vars are getting picked up only at the beginning
of a play.
If you know the set of groups you're creating with group_by, you can
Made a new pull request: https://github.com/ansible/ansible/pull/5494
On Friday, January 3, 2014 1:12:08 PM UTC-5, Matt Ferrante wrote:
The default won't be supported in new versions. I doubt people will run
into this right away, as they already have pip installed, but it will
probably
Hi all,
See what we decided to do here with regards to version checking:
https://github.com/ansible/ansible/commit/191be7b951eb8c34b73b367334e0cb4343af0779
I'll add the note that this flag is ignored on newer versions of pip.
On Fri, Jan 3, 2014 at 1:12 PM, Matt Ferrante
but it looks like this doesn't automatically load anything i have in
group_vars for those new groups
When you say new groups, do you mean the group is not defined in
inventory or is defined and does not have hosts?
In either case, I would like this would work, yes.
This seems like (if
Hey there,
I just realised that installing galaxy roles does not download the
dependencies listed in the meta/main.yml.
Take for example one of my roles, rails-deployment: meta/main.yml does list
my dependencies (which is properly formatted according to galaxy source:
I'm getting a permission error actually. Are you getting this when
visiting the dependency URL?
detail: You do not have permission to perform this action.
This is almost definitely on our side, but let me know the above and I'll
get this queued up.
I know we tested some dependency things, so
This email sounds like it's really assemble module not working with
remote_src=False.
Looking at the problem, it appears the code was written to not boolean-ify
the input arguments, which is definitely a bug. Please file a ticket if
you don't mind.
remote_src =
thanks! i'll keep an eye on the issue and test it out when it's resolved.
matt
On Fri, Jan 3, 2014 at 8:56 PM, Michael DeHaan mich...@ansibleworks.comwrote:
Thanks, there was a report about something about dynamic hosts and
host_vars (uncommon) recently so I think the fix is likely
27 matches
Mail list logo
