On Tue, Mar 4, 2014 at 8:03 AM, Dag Wieers <[email protected]> wrote:
> On Tue, 4 Mar 2014, Michael DeHaan wrote:
>
> 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.
>
>
> --
> -- dag wieers, [email protected], http://dag.wieers.com/
> -- dagit linux solutions, [email protected], http://dagit.net/
>
> [Any errors in spelling, tact or fact are transmission errors]
>
> --
> 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 [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/ansible-project/alpine.LRH.2.02.1403041339050.6649%40pikachu.3ti.be.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAEVJ8QPW%3DJ4T85MAVayAXpV9iACzETpcjBRpVwmWq3LSEPZL4g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
