19:05:18 #startmeeting ansible core public irc meeting 19:05:18 Meeting started Tue May 5 19:05:18 2020 UTC. 19:05:18 This meeting is logged and archived in a public location. 19:05:18 The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:05:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:05:18 The meeting name has been set to 'ansible_core_public_irc_meeting' 19:05:48 * cyberpear waves 19:06:12 #topic https://github.com/ansible/ansible/issues/69190 19:06:16 tremble ? 19:06:21 * bcoca waves 19:06:23 * tremble waves 19:06:30 * felixfontein also waves unrelatedly 19:07:44 I think we need a new agenda issue 19:07:51 Short version: When passed null (explicitly using YAML constructs) there's no type checking and required* assume it's set 19:08:24 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 i understand the ticket, not sure what you wanted to discuss 19:08:49 ah .. i think we all agree, discussed today at triage, its a bug 19:09:30 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 so I guess no backport? (which would be my main question, and I think 'no backport' is the way to go) 19:10:44 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 i think backport is fine, just might need a toggle to 'allow_none_value' for affected plugins 19:11:40 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 So you're of the opinion null should generally be treated as '{{ omit }}' ? 19:11:51 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 IMO `null` and `{{ omit }}` are different thinks 19:12:28 so maybe there is something to discuss :) 19:12:42 no, diff issue 19:13:29 omit doesnt pass keys, required_if might have only checked 'key presense' but it also seems to want 'value present' 19:13:55 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 now, most cases 'none' is not a valid value and should be an error 19:14:05 IMO 'key presence' is the correct thing to check, not 'value present' 19:14:14 tremble: no, type checking accepts null/none specificaly 19:14:39 felixfontein: maybe add new option if_required( ... non_null=no|yes) 19:15:09 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 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 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 anyone else want to weigh in? no other considerations on this tpoic? 19:34:30 I'm still somewhat confused 19:34:38 tremble: do you think you know what you need to write tests / try to fix this? 19:36:22 I think do... 19:37:49 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 k 19:44:33 #topic open floor 19:48:18 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 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 So May 30th, good to know 19:52:54 * cyberpear always forgets the up-to-date version is in git 19:52:56 yep, pretty soonish 19:53:07 usually devel is up-to-date as well 19:53:23 but right now the devel docs process is recreated, so that not almost all module docs vanish 19:53:29 is this still the best place to track blockers? https://github.com/ansible/ansible/projects/39 19:54:31 probably not, has not really seen any updates in long time, not sure anyone is still using it 19:54:44 consdier that most TODO entries are for stuff that lives in collections now 19:54:44 where is the current place such things are tracked? 19:54:51 is there a tag on issues we should follow? 19:54:51 good question 19:55:06 anything p1 or p2 is a blocker 19:55:06 used to be in the ROADMAP page, then got moved to GH projects 19:55:09 now... 19:55:23 it looks to me that the proper blockers are not in that project 19:55:29 the main one from my POV being routing/tombstoning 19:55:36 felixfontein: he, clearly 19:57:31 * cyberpear struggles to get GH to show both P1 and P2 at once 19:57:50 k, started updating the project 19:58:31 We aren't really using a project for 2.10 19:58:33 put all p1/p2 in project 19:58:56 I am only tracking high level objectives, of which there is only 1 remaining 19:59:02 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 he, added tombstone to it ... 19:59:27 I was only tracking 3 things, 2 are complete, 1 is left. 19:59:30 sivel: and that is "2.9 compatibility"? 19:59:34 also aded p1 and p2 s 19:59:42 felixfontein: tombstoning/routing 19:59:44 felixfontein: among other things, but mainly 19:59:52 how about action groups? 19:59:56 outside of that I have no concern over 20:00:34 felixfontein: added that to project, we should get that in if we can 20:00:37 It was not an originally approved feature, as such, it isn't something I am tracking 20:01:17 the 3 things were, list/verify ansible-galaxy CLI commands, migration, routing/tombstoning 20:01:25 sivel: what were the 3 approved features? 20:02:01 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 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 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 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 helps to understand why it's been so hard to track from a relative outsider perspective 20:04:40 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 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 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 thanks for pointing it out 20:05:40 I'm going to end up being responsible for the next releases too afaict 20:05:54 although, not from an actual release manager perspective 20:06:04 no funding for a RM? 20:06:27 we got a RE .. but no RM .. used to be floating position, but everyone that has been RM was totally overloaded ... 20:06:35 cyberpear: we have a release engineer, but release manager was kind of...yeah 20:06:52 growing pains + covid = ouch 20:07:11 also team was reorged to handle new 'ansilbe ecosystem' .. lots of balls in air 20:07:49 community , content and other teams took from what used to be 'big bag of core', still adjusting 20:09:14 k, going to close this meeting, will try to get better answers for 'project visibility' for next meeting 20:09:15 right, easy to forget there was a big change in work situations 20:09:25 #endmeeting