On Tue, Mar 4, 2014 at 8:58 AM, Dag Wieers <[email protected]> wrote: > 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. >
I was referring to things like facts.d And that they aren't gathered between tasks is not so important, but the fact that they would be intuitively re-gathered if you wrote another play. Most people do not set "gather_facts" behavior on a play at all, because gathering facts is not expensive to them. Brian in particular has some massively overloaded machines -- which, should there be an ASPCA for computer machines, would be recieving some industry protection. Most folks also run with sufficiently high forks values :) > > 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). > > I'd definitely disagree that everyone knew about it -- it wasn't clear even to *ME*. > > 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. > To be clear, that was merged by James Tanner, and we wasn't aware of the previous change. This was a communication error between us and not his fault :) > > 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. That was my error. The changelog is frequently updated retroactively and will continue to be on many occasions. Also due to the extreme pace at which this project moves there are times where we're going to miss something 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). > I'm not sure why this should be alarming to you. > > But a simple boolean to keep track whether setup was run could have been > sufficient. Perhaps, though the default state should be to gather facts. Like I've mentioned below I'd accept a "gather_facts: auto" and a configurable default in ansible.cfg > > 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. > > Now this is just getting nitpicky about commit messages. > > > 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 didn't. > > 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 a valid point. Perhaps it should be a new setting altogether. gather_facts: True/False It may also be better addressed by fact caching. > > 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. > > I'm always open to a discussion. And I don't really view it as complaint -- I see it as a need to have a discussion about what the project/code needs to be doing. This is what this list is for. > > 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... I'll say this, every time this kind of attitude comes up, it makes me want to help you less and less. And it takes time out of when we could be helping others. > > > -- > -- 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. > -- 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/CAEVJ8QMvH_FM_zJTP_xQh%3DiO_nMsLuj4Js1y%3D38qevgZw3o46A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
