The maintenance has been completed, please let us know if you experience
any issues.
Thanks!
On Fri, Apr 4, 2014 at 4:30 PM, James Cammarata wrote:
> There will be a small maintenance window tonight for Galaxy starting at
> 10PM EDT to deploy a few bug fixes and the following two major items:
>
It could very well be that the "implicit localhost" magic doesn't sit well
with the failure percentage code -- please make sure we have a github
ticket on this one with details of how to repro.
Thanks!
On Fri, Apr 4, 2014 at 3:51 PM, Marc Petrivelli
wrote:
> This is an interesting side effect o
A config setting seems reasonable. I hate that I don't remember how we got
down this path, but I think there's a good chance in some cases extra-sudo
was causing issues for people.
On Fri, Apr 4, 2014 at 3:34 PM, Dustin C. Hatch wrote:
> On Fri, Apr 4, 2014 at 1:09 PM, Michael DeHaan
> wrote:
On Saturday, April 5, 2014 2:23:13 AM UTC+11, Michael DeHaan wrote:
> It's not variables, rather, just facts.
>
> But yes, fixed on the development branch.
>
> We do not plan for a 1.5.4 update release at this time seeing 1.6 is due
> for towards the end of the month. This *may* change, but I'm
There will be a small maintenance window tonight for Galaxy starting at
10PM EDT to deploy a few bug fixes and the following two major items:
1) All roles starting with "ansible-(role-)" will be renamed so they no
longer contain that string. Also, moving forward, any roles that are
created will au
This is an interesting side effect of using local tasks vs plays with
hosts: 127.0.0.1.
In my case I was running a playbook and on the command line limiting with
-l command.
ansible-playbook -l host1 site.yml
in the play book I had the following play:
hosts: localhost
user: root
tasks:
On Fri, Apr 4, 2014 at 1:09 PM, Michael DeHaan wrote:
> Curious. Perhaps a global config setting for
> "prevent_apparent_useless_sudo" is needed.
>
> IIRC, this caused problems with prompts in some cases -- but maybe it didn't
> and someone was optimizing something that didn't need to be optimize
Perhaps the force is causing extra checking?
If so, maybe it can be removed.
On Fri, Apr 4, 2014 at 12:29 PM, Matt Martz wrote:
> I will mention that we use 'file' to recursively delete a directory, but
> it does require 'force=yes'
> --
> Matt Martz
> m...@sivel.net
>
> On April 4, 2014 at 8:
You've described it good enough, I'm saying it's meant to be that way.
I have also mentioned above about the protections in place on "vars", but
because "defaults" are inventory scope (so inventory can override them)
they do not apply to defaults.
Namespace your variables by prefixing them with t
Curious. Perhaps a global config setting for
"prevent_apparent_useless_sudo" is needed.
IIRC, this caused problems with prompts in some cases -- but maybe it
didn't and someone was optimizing something that didn't need to be
optimized.
On Fri, Apr 4, 2014 at 11:42 AM, Dustin C. Hatch wrote:
>
Without more context, it's impossible to tell what you mean, as this is
exactly the message you get after all the hosts have had failures.
Please supply some more context about your playbook run, execution, and so
on, and we can discuss further.
On Fri, Apr 4, 2014 at 12:02 PM, Marc Petrivelli
w
I didn't mean defaults -- I mean "we should set this as universally
required because we can't provide sensible defaults, or at least when the
module needs it"
On Fri, Apr 4, 2014 at 2:07 PM, Michael DeHaan wrote:
> We should either add the region parameter as universally required or
> provide s
We should either add the region parameter as universally required or
provide sensible defaults.
Please do file a bug on this.
Thanks!
On Fri, Apr 4, 2014 at 12:36 PM, i iordanov wrote:
> Hi Benno,
>
> Thanks, that did help. Now I get further. So this is a documentation issue.
>
> Now I am suf
Hi Benno,
Thanks, that did help. Now I get further. So this is a documentation issue.
Now I am suffering from a lack of a feature which is a different
issue. With the current code, I am unable to place the ELB into a VPC
which is necessary for my use-case.
Cheers!
iordan
On Fri, Apr 4, 2014 at
I will mention that we use 'file' to recursively delete a directory, but it
does require 'force=yes'
--
Matt Martz
m...@sivel.net
On April 4, 2014 at 8:48:36 AM, Maxim Odinintsev (gwynn@gmail.com) wrote:
Hello,
When I'm run this job, but on some hosts return output:
rmtree failed: [Errno 3
Hello,
I guess I havent described good enough. variables get inherited from other
roles if they are stored in defaults.
And if I run playbook with tags, I dont want variables to be inherited from
the role that is not called with tags in the particular play.
Is that current behaviour? Or vars are
I am getting
*FATAL: all hosts have already failed -- aborting *
even though none of the hosts are showing any errors. This problem
starting creeping up in the 1.5.x releases. Any ideas?
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To
Can you try passing "region: foo" as a parameter and see if that helps.
On Fri, Apr 4, 2014 at 8:57 PM, i iordanov wrote:
> Hi Michael,
>
> I just built Ansible from the latest devel branch and I'm still seeing
> the same error. I don't quite understand whether I need to patch the
> devel bra
On Fri, Apr 4, 2014 at 10:16 AM, Michael DeHaan wrote:
> "Unfortunately, it seems that
> Ansible thinks it is smarter than I am, and refuses to run my modules
> in sudo if the remote user is root, so everything fails with
> permission denied errors."
>
> This is true because sudo to the same user
Hi Michael,
I just built Ansible from the latest devel branch and I'm still seeing
the same error. I don't quite understand whether I need to patch the
devel branch with anything before testing.
If not, I've already tested with the latest devel branch and this is a new bug.
Thanks!
iordan
On Fr
On Thu, Apr 3, 2014 at 5:10 PM, Michael DeHaan wrote:
> Yeah I'm not seeing where you need this yet.
>
> Depends on the scale of your infrastructure, but plenty of very very large
> setups are not doing this -- and really, if you are in that area, treating
> cloud like cloud and using Ansible to
In case you weren't aware, there is a pretty full featured mysql role on
Ansible Galaxy. That may give you some hints.
https://galaxy.ansible.com/list#/roles/1
- James
On Tuesday, April 1, 2014 11:49:36 AM UTC-4, Patrick Ogenstad wrote:
>
> I've just gotten started with Ansible. I must say it'
BTW, please make sure there's a ticket filed for this.
Thanks!
On Fri, Apr 4, 2014 at 11:24 AM, Michael DeHaan wrote:
> Not without modifying the source to fix the root cause of the problem.
>
>
>
>
> On Fri, Apr 4, 2014 at 11:23 AM, Dario Bertini wrote:
>
>> On Fri, Apr 4, 2014 at 5:13 PM, M
Not without modifying the source to fix the root cause of the problem.
On Fri, Apr 4, 2014 at 11:23 AM, Dario Bertini wrote:
> On Fri, Apr 4, 2014 at 5:13 PM, Michael DeHaan
> wrote:
> >
> > (B) This variable really ought to be templated at an earlier level
> anyway.
> >
>
> Agree, is there
Sounds like a good feature request or pull request addition -- can you file
a ticket on github.com/ansible/ansible ?
On Fri, Apr 4, 2014 at 9:48 AM, Maxim Odinintsev wrote:
> Hello,
>
> When I'm run this job, but on some hosts return output:
> rmtree failed: [Errno 39] Directory not empty:
> '
On Fri, Apr 4, 2014 at 5:13 PM, Michael DeHaan wrote:
>
> (B) This variable really ought to be templated at an earlier level anyway.
>
Agree, is there something I could to do force the templating early, or
is it something that can be done only inside ansible itself?
--
xmpp: berda...@gmail.com
It's not variables, rather, just facts.
But yes, fixed on the development branch.
We do not plan for a 1.5.4 update release at this time seeing 1.6 is due
for towards the end of the month. This *may* change, but I'm thinking
probably it will not, since there's a workaround posted in the ticket
Yes.
Tags apply only to the tasks therein, not the variables themselves.
On Fri, Apr 4, 2014 at 11:18 AM, Marko_Lisica wrote:
> Thing is that I wanted to point out if I tag my roles, and run a play, is
> it intended to inherit vars from a role that is not in that particular play
> although it e
There have been some tickets open about ec2_elb recently:
Please review the following and see if your issues are addressed by the
latest on the development branch:
https://github.com/ansible/ansible/search?q=ec2_elb&ref=cmdform&type=Issues
If not and you are still seeing issues on the developmen
I should point out that trying to code in playbooks is usually the sign
that you're trying too hard to do something.
It should almost always be thought of as "what is the easier way?"
If syntax looks offensive, it is a sign simplification is needed -- that's
the Ansible way, basically.
A simple
Thing is that I wanted to point out if I tag my roles, and run a play, is
it intended to inherit vars from a role that is not in that particular play
although it exists in playbook, but it is excluded in particular run
because of tags.
On Fri, Apr 4, 2014 at 5:10 PM, Michael DeHaan wrote:
> Def
Hello!
I may be doing something wrong, but I tried so many different things, I
though it should report just in case. So far, I've tried Ansible 1.5 built
from the repository and from Debian testing, and Ansible 1.6 (build from
today's devel branch state). Also, I've tried with python-boto 2.9.x
"Unfortunately, it seems that
Ansible thinks it is smarter than I am, and refuses to run my modules
in sudo if the remote user is root, so everything fails with
permission denied errors."
This is true because sudo to the same user causes problems on lots of
systems.
This is the first I've heard o
Correct.
On Fri, Apr 4, 2014 at 8:58 AM, Maxim Odinintsev wrote:
> Yes, this is valid syntax and this conditions working as AND. And it
> working for me ;)
> You can create simple playbook for verifying it.
>
>
> I've never seen this syntax used with when:
>>
>> - name: Moving on
>> debug: m
There's no mechanism for killing stuck processes other than say running
pkill.
(However if you use "async" you can set a lifetime time limit for a process
and it will be forcibly slain if that time limit is reached)
That's what's there now.
On Fri, Apr 4, 2014 at 8:15 AM, Rike-Benjamin Schuppn
"You're right, anyhow this is a regression introduced with ansible 1.5.0"
(A) I don't think we can say any possible behavior where something strange
used to work and doesn't is a regression, unless that behavior was either
documented or had a unit test for it.
(B) This variable really ought to be
Defaults load into inventory scope.
What I said applies to things in vars/
On Fri, Apr 4, 2014 at 3:11 AM, Marko_Lisica wrote:
> Hi,
>
> That is 100% clear. But in this case one role does not have its own
> defaults and inherits defaults from the last role in a list regardles if
> that role is
There have been pull requests for a random Jinja2 filter, but they were
pretty complicated in terms of syntax (i.e. not pretty syntax wise) and I
wanted to see them pared down.
On Thu, Apr 3, 2014 at 11:49 PM, Brian Green wrote:
> Where are you using the rsnap_daily_hour variable? The task
I'd welcome experimentation with the callbacks classes maybe, I don't think
a thing on top of ansible is appropriate.
On Thu, Apr 3, 2014 at 7:54 PM, Yaroslav Halchenko wrote:
> FWIW I would second having such a feature builtin, e.g. even just having
> something like a --collate option woul
Hello,
When I'm run this job, but on some hosts return output:
rmtree failed: [Errno 39] Directory not empty:
'/home/master/www/static.master/images/posters'
Sure this directories is not empty, and I'm want remove it recursive. But
why i can't do this with file module ?
- name: Cleaner
hosts
This issue was reported the other day and has been fixed in the devel
branch:
https://github.com/ansible/ansible/issues/6832
You can grab that patch for now if you'd like (
https://github.com/ansible/ansible/commit/9c6dd9f79c6fbed3346b951fc280f30cb6d676ae),
which will be included in the next rele
Hi Matt,
That is a great suggestion! I will give it a try.
I overcame this by using this task:
- name: check mount point
shell: mount | sed -n -e '/\/var\/lib\/myMount.*/p'
register: result
and after that using the result variable on the when statement:
when: result.stdout==""
It looks li
In my environment, when a VM is first provisioned, it has no users
other than root, and root has no password. The machines are pre-seeded
with an authorized SSH key so I can log in as root remotely to finish
the set up. These machines have SELinux enforcing the strict policy,
so even logging in as
Yes, this is valid syntax and this conditions working as AND. And it
working for me ;)
You can create simple playbook for verifying it.
I've never seen this syntax used with when:
>
> - name: Moving on
> debug: msg="doing something with {{ item.item }}"
> when:
> - item.stat.exists == tru
Douglas,
You won't be able to use pure python in a when statement, you will have to
handle it using jinja2.
I see 2 options for you:
1) Use a combination of several jinja2 filters to get you what you want such as:
when:
ansible_mounts|map(attribute='mount')|intersect(['/var/lib/myMount'])|len
So, this means there is no good answer for cleaning up / ad-hoc debugging
or was it just the question which was unclear? It happens regularly that
ansible gets stuck on some machine (doing apt upgrades) and I don’t see any
practical way of finding out even where it got stuck and why.
Cheers
/ri
You're right, anyhow this is a regression introduced with ansible 1.5.0
--
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...@googlegrou
I have a playbook with the following:
vars_files:
- "vars/{{ ansible_pkg_mgr }}.yml"
... that works fine in 1.5.3, but 1.5.4 doesn't appear to be able to find
it; when one of the variables that should have been imported is referenced,
it throws a 'foo is undefined' error.
I can provide a
Hi,
That is 100% clear. But in this case one role does not have its own
defaults and inherits defaults from the last role in a list regardles if
that role is played or not.
On Fri, Apr 4, 2014 at 12:16 AM, Michael DeHaan wrote:
> It's entirely intended. For instance, you might have a role tha
49 matches
Mail list logo
