On Tue, 4 Mar 2014, Michael DeHaan wrote:
On Tue, Mar 4, 2014 at 8:03 AM, Dag Wieers <[email protected]> wrote:
On Tue, 4 Mar 2014, Michael DeHaan wrote:
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.
What you call "dynamic facts" is simply rerunning setup at the start of
every play. But they are not dynamic because the next task won't have them
either.
In most if not all cases facts are static, and in case you want to
re-enforce facts gathering, you could simply enable that for a specific
play. Or even better, run the setup module within a play. There is no need
for re-running the setup module at the start of every play. The overhead
is big and the opportunities are scarce, especially if you properly
structure your playbooks with self-contained plays.
This was an untuitive behavior, was never documented, and was removed.
It was not unintuitive, everyone understood this well, nobody complained
about it and could have been documented (like many other things that are
not documented yet).
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.
I asked it on IRC, send in a fix and it was accepted and reverted.
BTW That technical discussion was not held, the decision was made when you
committed it for v1.5 and released it as part of v1.5. Reverting now is
harder because suddenly this is the default in v1.5.
What's even more, it was not even announced as a change in the ChangeLog.
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.
Well, my solution would have looked very differently. To me it is a design
fault if variables you register end up in the SETUP_CACHE (!). That's
very alarming to me (not knowing that part of the code).
But a simple boolean to keep track whether setup was run could have been
sufficient. In the ansible-provisioning project we actually have different
namespaces for different facts modules, and there is a special fact
module_<name> which is set if that specific module has run once. Such a
mechanism could have been sufficient to fix this corner case.
BTW In the discussion of pull request you never mentioned what exact
problem was fixed by removing the old behaviour. It could help if commits
would give a proper description to why it was needed, and what it changes.
SOmething you expect from external pull requests anyway.
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.
Like you didn't do about me, right ? :)
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?
How is that any different as it was. You complained about gather_facts
having three states before and it not being a boolean. And now you propose
to make it a three-state entity again ?
That's the kind of technical discussion I like to have.
Sure, BEFORE you release something as ansible v1.5.
You are ignoring the fact that you committed it and released it in a
new release, only then when people complain to give the notion you prefer
to have a proper technical discussion about it.
Sure gather_facts: auto is fine by me. But it would have been a lot better
if that was what shipped with Ansible v1.5 in the first place. Now it
simply looks as nobody has real control over what's going on unless you
give your final say. And then we have the technical discussion...
--
-- 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.1403041422360.6649%40pikachu.3ti.be.
For more options, visit https://groups.google.com/groups/opt_out.
