Or should we say, it escapes!
And it’s on PyPi now.
http://blog.ansibleworks.com/2014/02/28/ansible-1-5-released/
Read the blog link above for details, and if you don’t want to download via pip you can hit releases.ansible.com too.
–Michael
Awesome, I’ve been looking forward to the new Docker modules in this release.
Question, I’ve uninstalled Fedora’s Ansible package so I can use the latest from Pypi. I run:
pip install --user ansible
But the package still tries to create files outside my home directory. Is there a way around this?
I get that I’ll have to set my own module search path, but I’d like it to respect my request to install with --user. Thanks.
I was doing brew update, upgrade, and noticed that Ansible is 1.5 before reading it over here. thanks to everyone that made it possible.
Great work, thank you! I updated to this version yesterday specifically
for the "implicit localhost" behavior. It is very helpful since my
management machine has Python 3 installed at /usr/bin/python.
I did notice, though, that ansible-playbook seems to gather facts
between every play now, as opposed to once at the beginning like it did
in 1.4.3. Is this intended behavior? I don't see any mention of it in
CHANGELOG.md, but I could be overlooking something.
Regards,
Are you not setting gather_facts in each of your plays?
We noticed the same thing. Facts are gathered for every play, rather than once per playbook.
The playbook does not mention gather_facts, nor did we specify anything in /etc/ansible/ansible.cfg related to facts gathering.
Ok, I can see the change that was made. In the past gather_facts had 3 states: None, True and False. Now there's only True and False, and the default is True, in which case "setup" is being run at the start of every play as if "gather_facts: yes" was added.
I went through this logic when attempting to add caching, the None state gathered facts only if the cache was empty (implied true), if the play had an explicit gather_facts: True it would ‘refresh the cache’.
This was a nice optimization, removing it is making all my ‘concatenated plays’ a lot slower.
We’re pretty far off topic here, but I’m curious what you mean by plays versus playbooks here…
The documentation states that I can turn off fact gathering by explicitly setting gather_facts: no in my playbook… I have not upgraded to 1.5 yet, so I haven’t tested this, but I would want to do a gather_facts once at the beginning, but not for every task, or even role…
Adam
Apparently the "run setup for every play" is works-as-designed in 1.5.0.
https://github.com/ansible/ansible/pull/6251
But remember, this is not a democracy, and if it was, the silent majority has already spoken ! 
It just happens once per play.
A playbook is a group of plays, in fact a list of them
A play takes a group of hosts and applies a list of roles and tasks to them
– Michael
This is not the question that the poster asked Dag (plays vs tasks) -
and I'm disappointed in the way you are approaching this discussion
from a position that assumes a shadow conspiracy.
Discuss a technical solution if you like but there is no need for the hyperbole.
-- Michael
I approached this discussion with a patch to revert to the previous behaviour.
The discussion is NOT plays vs tasks, again you have not understood what I said in the issue ticket (or what bcoca said). ANd there is no shadow conspiracy, it is mostly history repeating. You have a conviction and it does not matter what people say. Every other view is a rare use-case.
Michael, you own this project and you give the direction. It doesn't matter what I say or what I think. And if you wonder why I am frustrated, THAT is exactly it. You make changes without even discussing it on this list, and this is not the first time it happened and it won't be the last. My patch for this regression was accepted, than reverted because nobody knows what is a bug and what is design.
Your reason for this change is that it was never documented, and therefore there is no specification to what is the correct behaviour. My position is that how it worked for everyone the past 2 years is how people expect it to behave. So the easiest solution is to document the existing behaviour, instead of changing the behaviour.
So I come back to my remark, if the majority doesn't care and this is not a democracy, the new way is works-as-designed. Have it your way !
So yes, I don't understand why you would want to undo the speed improvements of 1.5.0 with a (default) mandatory facts gathering at each play. Presumably because a task can change the facts. Well, if that's your concern, you should force a facts gathering per task (because every task can change facts and that has also not been documented). Or instead, leave it up to the user to decide when to gather facts, but do it at least once. (The way it always worked since Daniel Hokka Zakrisson (dhozac) implemented it)
With the current change there is no guarantee that all systems have facts gathered, so if you start ansible 1.5 with a:
This is not the question that the poster asked Dag (plays vs tasks) -
and I'm disappointed in the way you are approaching this discussion
from a position that assumes a shadow conspiracy.Discuss a technical solution if you like but there is no need for the
hyperbole.I approached this discussion with a patch to revert to the previous
behaviour.The discussion is NOT plays vs tasks, again you have not understood what I
said in the issue ticket (or what bcoca said). ANd there is no shadow
conspiracy, it is mostly history repeating. You have a conviction and it
does not matter what people say. Every other view is a rare use-case.Michael, you own this project and you give the direction. It doesn't
matter what I say or what I think.
Actually it is does matter what everybody thinks to me. Quite a lot!
I'll recap for the purposes of the list:
The question is removal of an undocumented and unclear flag, that modelled
what was a "Tri-state" boolean.
In this case, if gather_facts was not explicitly set True, it was assumed
"None", which meant "gather facts for hosts you have not talked to yet".
This means that any host that has registered something will be skipped in
later plays, and can't have facts that are dynamic.
This was an untuitive behavior, was never documented, and was removed.
And if you wonder why I am frustrated, THAT is exactly it. You make
changes without even discussing it on this list, and this is not the first
time it happened and it won't be the last.
Yes, this is true.
Ansible is our project, and we're not going to spin a wheel every time we
want to change something and say "please may I". However, we are going to
use our combined experience of talking to thousands upon thousands of
users, and do that to best help everyone here.
When that is done, if we occasionally screw up -- and we will -- it's best
to ask how we can fix it, and that will result in a technical discussion.
My patch for this regression was accepted, than reverted because nobody
knows what is a bug and what is design.
Something that has never been a documented feature, that actually breaks
parts of Ansible, is not a regression. But it's a fair concern, so read
below...
Your reason for this change is that it was never documented, and therefore
there is no specification to what is the correct behaviour. My position is
that how it worked for everyone the past 2 years is how people expect it to
behave. So the easiest solution is to document the existing behaviour,
instead of changing the behaviour.
Perhaps. if it's what we wanted, but I still don't feel it's the right
behavior -- and it's always been the aim of the project to believe that if
something documented is confusing, the feature is confusing, and it
shouldn't be done that way -- fix the system until the docs are *EASY*.
I'll be straight though. Ansible was a different project two years ago.
I was running things as a project in my spare time, and I was *MUCH* more
inclined to auto-merge things that people wanted.
In the past (and they are great people), Daniel and Stephen also had direct
commit access. That isn't true now and we review things closer, we care
about consistency closer, and we care about code a bit more -- that's not a
knock at them, that just means we are taking things a lot more seriously
than when this was a "nights and weekends" project.
In this case the code in question was causing problems -- and it was
undocumented behavior that would be confusing to most -- and also it was
overloading a boolean in a way that was VERY confusing and wouldn't allow
anyone using the boolean to rely on the truthiness of the boolean.
So I come back to my remark, if the majority doesn't care and this is not
a democracy, the new way is works-as-designed. Have it your way !So yes, I don't understand why you would want to undo the speed
improvements of 1.5.0 with a (default) mandatory facts gathering at each
play. Presumably because a task can change the facts. Well, if that's your
concern, you should force a facts gathering per task (because every task
can change facts and that has also not been documented). Or instead, leave
it up to the user to decide when to gather facts, but do it at least once.
(The way it always worked since Daniel Hokka Zakrisson (dhozac) implemented
it)
The gather_facts on each play is still not mandatory, as you can have a
explicit
gather_facts: "no" on each play.
What I didn't like was how gather_facts <previous implementation> broke the
ability to gather new facts, which is a serious concern, and how it relied
on SETUP_CACHE to make that decision, which is also sketchy.
With the current change there is no guarantee that all systems have facts
gathered, so if you start ansible 1.5 with a:----
- hosts: webservers
tasks:
- action: ping- hosts: all
gather_facts: no
tasks:
- action: ping
----You won't have facts except for the webservers. Whereas in the past (pre
1.5) you could simply do:----
- hosts: webservers
tasks:
- action: ping- hosts: all
tasks:
- action: ping
---
I understand the above and appreciate the technical discussion. To be
clear, it could be done like it was intended with:
- hosts: all # or whatever group of systems where this is needed
gather_facts: True # default
tasks:
- hosts: webservers
gather_facts: False
tasks:
- some_meaningful_action
And this also has the benefit of removing the ping step. It will also
perform the exact same number of tasks, and I think it's also more
explicit, which is also Ansible's nature.
And all systems would eventually have facts gathered one time. So total
control of facts gathering in 1.5 makes the default case worse, either
because you have facts gathered at every play (overhead), or because you
have to be careful in order to have facts gathered for all your hosts if
you would like to avoid the overhead.If you keep up with the existing implementation in v1.5, I am going to
recommend people to always start with:----
- hosts: all
gather_facts: no
tasks:
- action: setup
This can be written a lot more clearly with gather_facts: yes and a null
tasks block.
- hosts: webservers
gather_facts: no
tasks:
- action: ping
----Simply to ensure you have facts for each host, and then disable facts
gathering on every subsequent play to avoid the additional overhead of
running the setup module.I know I am not going to change your mind, but I care too much to not even
try to make the case (that you seem to ignoring).
See, this is what I hate here -- you're jumping to assumptions about me
already.
I'm not against providing a *better* way to solve this problem, that's more
clear and explicit, but the existing hack (being default behavior) was
breaking things and was not a good way to go.
What about simply looking at this as "gather_facts: auto" being a new mode,
and also being able to set that default in ansible.cfg?
That's the kind of technical discussion I like to have.
We're going to disagree from time, but I think many people know I can be
persuaded with logic. In this case the existing behavior is a 'secret' of
a patch and not one I agree with, but it's not saying we can't have similar
functionality exposed in clearer ways.
the gather_facts: false in subsequent plays works if they are all in the same playbook. But it breaks when doing (and all plays using facts):
- include: playA.yml
- include: playB.yml
- include: playC.yml
Which is a pretty common setup, specially for site.yml and still allows you to run the plays individually. From irc and tickets this is a pretty common use case, I understand that it is undocumented/unclear behavior but I think a better change is through documentation vs removing the way this has worked in the experience of the majority of the users.
Also I have not heard about issues with facts not being refreshed, aside from add_host, group_by which now specifically force a gather/cache invalidation.
I think you are ‘fixing’ it for the rare case, which could also be solved easier by just documenting the feature or adding a default ‘cached’ option that would be clear, explicit and still work as it has (which is pretty optimal for 99% of the usage).
I wasn't aware of this, whilst I now understand why it mishappened that
way.
I guess this is the key part in this change.
It would have solved a lot of questions though if this would have been made
more clear. Like e.g. when Dag's merged patch was reverted.
Given the big change in behavior, at least a notice on the mailing list and
a mention in the CHANGELOG would have been a good practice.
Now all back to work 
Serge
"All problems are caused, at some level, by poor communication."
“the gather_facts: false in subsequent plays works if they are all in the same playbook. But it breaks when doing (and all plays using facts):”
Are you sure?
Facts within the same Ansible run (different plays) are not cleared.
not what I meant, I meant that the gather_facts:false doesn’t work for this case as when those plays get executed individually, they won’t have facts. If left to true, then when executing in same run they will all trigger a fact gathering even if not needed.
They would if the first play was an empty fact gathering play.
(I understand what you are getting at with not having one)