15:01:19 <sdoran> #startmeeting Ansible Core Public IRC Meeting https://github.com/ansible/community/issues/519
15:01:19 <zodbot> Meeting started Thu Feb 13 15:01:19 2020 UTC.
15:01:19 <zodbot> This meeting is logged and archived in a public location.
15:01:19 <zodbot> The chair is sdoran. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:19 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting_https://github.com/ansible/community/issues/519'
15:01:40 <sdoran> #topic https://github.com/ansible/ansible/issues/50278
15:04:44 <felixfontein> isn't the meeting in one hour?
15:05:04 <sdoran> I don't think so.
15:05:23 <felixfontein> hmm, then I'm seriously confused :)
15:05:29 * sdoran double checks
15:06:18 <felixfontein> you're right
15:06:36 <sdoran> Thursdays 1500 UTC.
15:06:51 <tremble> my calendar went bong, so I think it's the right time.
15:07:08 <felixfontein> good :)
15:13:43 <felixfontein> Pilou: ping
15:13:43 <zodbot> felixfontein: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
15:15:03 <jtanner> hi
15:15:24 <sdoran> #chair jtanner felixfontein tremble
15:15:24 <zodbot> Current chairs: felixfontein jtanner sdoran tremble
15:15:34 <sivel> yo
15:16:06 <sdoran> #chair sivel
15:16:06 <zodbot> Current chairs: felixfontein jtanner sdoran sivel tremble
15:16:33 <sdoran> So it seems like we just need to unify the docs and potentially fix a bug?
15:16:58 <sdoran> Further define "role params".
15:17:35 <bcoca> role params, like include params is something we wanted to eliminate, since they conflate keywords and variables
15:17:45 <bcoca> why 'name' had sidefects when used in roles:
15:17:48 <sdoran> #chair bcoca
15:17:48 <zodbot> Current chairs: bcoca felixfontein jtanner sdoran sivel tremble
15:18:08 <sdoran> So it seems we should document that, and change our examples to use `vars` everywhere.
15:18:27 <sivel> Can someone explain what "bug" is being referenced?
15:18:33 <bcoca> sdoran: vars has diff implications
15:19:09 <bcoca> not as much a bug but a conflict between 2 systems that work in opposite ways by design
15:19:12 <sdoran> sivel: https://github.com/ansible/ansible/issues/50278#issuecomment-451186694
15:19:26 <sdoran> Maybe I misinterpreted that as a bug.
15:19:31 <bcoca> role 'vars' are forcefuly exported with high precedence, while all other 'vars' are contained at diff precedence
15:19:35 <sdoran> Maybe you were just explaining the current (correct) behavior.
15:20:02 <bcoca> so 'nomral' vars specificity is thrown overboard when it comes to roles
15:20:26 <bcoca> well ... i never considered it 'correct', but i was no the one designing it ...
15:20:38 <bcoca> and changing it now will break a lot of playbooks
15:20:38 <sivel> sdoran: It may be a bug, that is undetermined.
15:20:46 <sdoran> <nod>
15:20:55 <sivel> I'll just say "it's complicated" and I really have no intention of looking into it more than I did in that issue
15:20:56 <bcoca> sivel:  more 'undocumented' but it is pretty detereministic
15:21:19 <sivel> I think my explanation indicates the same
15:21:35 <sivel> explanation in that issue*
15:22:21 <bcoca> it does
15:22:29 <sdoran> So we don't intend to change the current behavior, but we should at least document it, correct?
15:22:39 <sivel> documenting it might not be that easy
15:22:39 <sdoran> "These are role params, don't use them".
15:22:47 <sdoran> Darn.
15:22:59 <bcoca> its really 'there are these 12 (that we know of) corner cases with vars and roles'
15:23:08 <bcoca> role params also have problems
15:23:12 <sivel> Well, documenting the specific behavior outlined in that issue, will be really complicated
15:23:15 <bcoca> why we moved away from them
15:23:34 <sivel> Switch to `include_role`, and don't use `public`
15:24:01 <bcoca> ^ mostly solves these things, still have issues with precedence in role being diff
15:24:37 <sivel> yeah, I'll go back to "it's complicated", but just using `include_role` as a recommendation, will solve most
15:24:50 <bcoca> agreed
15:27:39 <sdoran> So could we just change the examples in the docs to not mention role params and instead use `vars` and/or `include_role`?
15:27:44 <sdoran> That may alleviate confusion.
15:28:05 <sdoran> And have a disclaimer about role params somewhere. "It's complicated, don't use these."
15:30:35 <sivel> Every feature has it's use. I'm not inclined to hide already documented functionality
15:31:07 <sivel> I think the best way to improve the situation, is just better docs explaining these concepts
15:31:32 <sdoran> OK.
15:35:50 <sdoran> So is the current behavior the desired behavior?
15:35:56 <sdoran> > what is the expected behavior ? role params would bleed, role vars: should not or the current one ?
15:38:16 <bcoca> 'desired' is strong word
15:38:22 <sdoran> :)
15:38:39 <bcoca> 'accepted cause it is grandfathered in and initially it was really hard to convice author it was not good idea'
15:39:08 <sdoran> So if we're not going to change it, then we should just improve docs to explain (as best we can) how it works.
15:47:39 <sdoran> #action update role docs to clarify (as much as possible) current behavior of role params vs role vars
15:47:43 <sdoran> #topic open floor
16:43:06 <sdoran> #endmeeting