19:05:18 <bcoca> #startmeeting ansible core public irc meeting
19:05:18 <zodbot> Meeting started Tue May  5 19:05:18 2020 UTC.
19:05:18 <zodbot> This meeting is logged and archived in a public location.
19:05:18 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:05:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:05:18 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
19:05:48 * cyberpear waves
19:06:12 <bcoca> #topic https://github.com/ansible/ansible/issues/69190
19:06:16 <bcoca> tremble ?
19:06:21 * bcoca waves
19:06:23 * tremble waves
19:06:30 * felixfontein also waves unrelatedly
19:07:44 <felixfontein> I think we need a new agenda issue
19:07:51 <tremble> Short version: When passed null (explicitly using YAML constructs) there's no type checking and required* assume it's set
19:08:24 <tremble> tremble, This caught me out, and I wanted the opinion of Core devs on how things *should* behave before poking too deeply
19:08:29 <bcoca> i understand the ticket, not sure what you wanted to discuss
19:08:49 <bcoca> ah .. i think we all agree, discussed today at triage, its a bug
19:09:30 <bcoca> just not something that looks high priority, its been like that for a long time and no one had hit, any fix would still require a portingguide entry jic, also look at some moules that use "none' as a valid value
19:10:11 <felixfontein> so I guess no backport? (which would be my main question, and I think 'no backport' is the way to go)
19:10:44 <tremble> yeah, I was planning on poking at it myself, but didn't want to dive headlong into it going against the behaviour the core devs think is 'correct'
19:11:06 <bcoca> i think backport is fine, just might need a toggle to 'allow_none_value' for affected plugins
19:11:40 <bcoca> since 99% of modules will be fine with change, it seems easy enough to add 'opt out' for those using None/null values
19:11:40 <tremble> So you're of the opinion null should generally be treated as '{{ omit }}' ?
19:11:51 <felixfontein> it looks like some people (like the AWS integration tests) use `null` instead of `{{ omit }}` right now, so it will break for them
19:12:23 <felixfontein> IMO `null` and `{{ omit }}` are different thinks
19:12:28 <felixfontein> so maybe there is something to discuss :)
19:12:42 <bcoca> no, diff issue
19:13:29 <bcoca> omit doesnt pass keys, required_if might have only checked 'key presense' but it also seems to want 'value present'
19:13:55 <tremble> Should the `null` be treated as not matching the 'type' checking, or should it be treated as not matching the 'required' checking...
19:13:58 <bcoca> now, most cases 'none' is not a valid value and should be an error
19:14:05 <felixfontein> IMO 'key presence' is the correct thing to check, not 'value present'
19:14:14 <bcoca> tremble: no, type checking accepts null/none specificaly
19:14:39 <bcoca> felixfontein: maybe add new option if_required( ... non_null=no|yes)
19:15:09 <bcoca> afaict most modules expect non null value there, that is why i thought default should be yes, but the 'really backwards compat' is defaulting to no
19:23:24 <felixfontein> that sounds complicated, and if there really is a module which allows `null` as a valid required value for strings, ints, ..., I think that module is wrong
19:24:26 <bcoca> there are reasons to allow None/null values sometimes, mostly they are 'default' .. but it does look like at least one module that does was by mistake.
19:33:27 <bcoca> anyone else want to weigh in? no other considerations on this tpoic?
19:34:30 <felixfontein> I'm still somewhat confused
19:34:38 <felixfontein> tremble: do you think you know what you need to write tests / try to fix this?
19:36:22 <tremble> I think do...
19:37:49 <tremble> At the very least I should be able to put together an initial set of integration tests that layout what I understand the behaviour should be...
19:44:29 <bcoca> k
19:44:33 <bcoca> #topic open floor
19:48:18 <cyberpear> any schedule for freeze for 2.10?
19:48:44 * cyberpear has several outstanding PRs that need docs or tests followup prior to merge
19:52:12 <felixfontein> cyberpear: the most current roadmap is here: https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_10.rst
19:52:33 <cyberpear> So May 30th, good to know
19:52:54 * cyberpear always forgets the up-to-date version is in git
19:52:56 <felixfontein> yep, pretty soonish
19:53:07 <felixfontein> usually devel is up-to-date as well
19:53:23 <felixfontein> but right now the devel docs process is recreated, so that not almost all module docs vanish
19:53:29 <cyberpear> is this still the best place to track blockers? https://github.com/ansible/ansible/projects/39
19:54:31 <bcoca> probably not, has not really seen any updates in long time, not sure anyone is still using it
19:54:44 <bcoca> consdier that most TODO entries are for stuff that lives in collections now
19:54:44 <cyberpear> where is the current place such things are tracked?
19:54:51 <cyberpear> is there a tag on issues we should follow?
19:54:51 <bcoca> good question
19:55:06 <bcoca> anything p1 or p2 is a blocker
19:55:06 <cyberpear> used to be in the ROADMAP page, then got moved to GH projects
19:55:09 <cyberpear> now...
19:55:23 <felixfontein> it looks to me that the proper blockers are not in that project
19:55:29 <felixfontein> the main one from my POV being routing/tombstoning
19:55:36 <bcoca> felixfontein: he, clearly
19:57:31 * cyberpear struggles to get GH to show both P1 and P2 at once
19:57:50 <bcoca> k, started updating the project
19:58:31 <sivel> We aren't really using a project for 2.10
19:58:33 <bcoca> put all p1/p2 in  project
19:58:56 <sivel> I am only tracking high level objectives, of which there is only 1 remaining
19:59:02 <bcoca> sivel: just updated it, we should really start using it, unless there is new place we are keeping track (i cannot really find)
19:59:08 <bcoca> he, added tombstone to it ...
19:59:27 <sivel> I was only tracking 3 things, 2 are complete, 1 is left.
19:59:30 <felixfontein> sivel: and that is "2.9 compatibility"?
19:59:34 <bcoca> also aded p1 and p2 s
19:59:42 <sivel> felixfontein: tombstoning/routing
19:59:44 <bcoca> felixfontein: among other things, but mainly
19:59:52 <felixfontein> how about action groups?
19:59:56 <sivel> outside of that I have no concern over
20:00:34 <bcoca> felixfontein: added that to project, we should get that in if we can
20:00:37 <sivel> It was not an originally approved feature, as such, it isn't something I am tracking
20:01:17 <sivel> the 3 things were, list/verify ansible-galaxy CLI commands, migration, routing/tombstoning
20:01:25 <cyberpear> sivel: what were the 3 approved features?
20:02:01 <sivel> that's basically it. We didn't really have a release manager for this release. I just put myself in the doc for lack of anyone else
20:02:14 <nitzmahone> action_groups mostly falls under the 2.9 compatibility- it's the only way to keep them working post-collectionizing. shertel has it mostly done, just blocked on the routing part (like everything else :I )
20:02:53 <sivel> Since we have no real release manager, we have no one tracking a project. I am only tracking the things I was told needed to happen
20:03:51 <bcoca> sivel: im goint to add some things to the TODO, we should have meeting to go over the stuff we want/need for 2.10 and establish priorities
20:04:07 <cyberpear> helps to understand why it's been so hard to track from a relative outsider perspective
20:04:40 <sivel> go for it. that is outside of my purview. Everything outside of the 3 things I listed are nice to haves in the eyes of my goals
20:04:56 <bcoca> cyberpear: lots of changes, we dropped the ball here as team, sivel stepped up to get collections out, but this was never on his lap to do, others had commited to do so, but .. again .. many changes
20:05:33 <cyberpear> thanks for the info, though.  Marking May 30th as the date before which I should have everything on my end cleaned up and merged
20:05:35 <bcoca> thanks for pointing it out
20:05:40 <sivel> I'm going to end up being responsible for the next releases too afaict
20:05:54 <sivel> although, not from an actual release manager perspective
20:06:04 <cyberpear> no funding for a RM?
20:06:27 <bcoca> we got a RE .. but no RM .. used to be floating position, but everyone that has been RM was totally overloaded ...
20:06:35 <sivel> cyberpear: we have a release engineer, but release manager was kind of...yeah
20:06:52 <bcoca> growing pains + covid = ouch
20:07:11 <bcoca> also team was reorged to handle new 'ansilbe ecosystem' .. lots of balls in air
20:07:49 <bcoca> community , content and other teams took from what used to be 'big bag of core', still adjusting
20:09:14 <bcoca> k, going to close this meeting, will try to get better answers for 'project visibility' for next meeting
20:09:15 <cyberpear> right, easy to forget there was a big change in work situations
20:09:25 <bcoca> #endmeeting