23:59:17 #startmeeting Ansible Azure Working Group 23:59:17 Meeting started Wed Apr 17 23:59:17 2019 UTC. 23:59:17 This meeting is logged and archived in a public location. 23:59:17 The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot. 23:59:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 23:59:17 The meeting name has been set to 'ansible_azure_working_group' 23:59:28 Hello 23:59:28 #chair jborean93 yungezz 23:59:28 Current chairs: jborean93 nitzmahone yungezz 23:59:33 Hiya 23:59:50 Hello Matt and Jordan 00:00:29 Hi zim 00:00:35 hey 00:00:38 good morning :-) 00:00:48 #chair zikalino826544 00:00:48 Current chairs: jborean93 nitzmahone yungezz zikalino826544 00:01:04 Jake from our cloud team is lurking today ;) 00:01:30 Welcome 00:01:57 :wave: 00:02:05 #chair yuwei 00:02:05 Current chairs: jborean93 nitzmahone yungezz yuwei zikalino826544 00:02:08 Hi zim, do you want to talk about the subs id Pr? 00:02:36 ah, yes, just let me find it 00:03:00 here: https://github.com/ansible/ansible/pull/55203 00:03:43 so apparently subcription_id is masked in returned facts when credentials are passed as parameters 00:04:06 what makes all returned resource ids useless (as in linked issue) 00:04:14 ah, yeah, it's the stupid heuristic masking 00:04:19 we were just wondering why it was masked in first place 00:04:47 also the issue submitter suggests client_id and tenant should be not masked either 00:04:48 The heuristic masker tries to "help" by finding return values named the same as a no_log value (eg in invocation block) 00:05:01 but i don't think these are important 00:05:14 Actually this is a bug in the underlying Ansible module_util 00:05:33 so is there anything we didn't consider, or should we just merge this fix? 00:05:56 It's better to keep things working if we merge the fix 00:06:32 But I'll make an issue to revisit the heuristic masking, or at least to have an explicit way to "opt out" where we say "this return value *needs* to be returned unmasked. 00:06:54 (it's an Ansible-wide issue, but most things don't run into it) 00:07:36 actually, i understood so far that no_log means it shoudlnt' be displayed, but it's completely removed from returned value 00:07:54 it scans all return values and masks it if the value is found 00:08:10 * nitzmahone hates that behavior, as it's overly blunt and causes dumb problems like this 00:08:13 yep 00:08:50 So yeah, fine to merge the change, and we'll revisit how best to solve it longer-term 00:09:09 ok, thx! 00:09:11 Great 00:09:19 It's probably not necessary for the others, as you say I'm not aware of any modules returning those values right now 00:10:24 Anything else from your side today? We have something here if not... 00:10:34 We found 2.8 release delayed 00:10:45 I don’t have any other topic 00:10:46 well, i think not from me... 00:11:18 Yeah, apparently there have been some issues with packaging and late-breaking security things, and the 2.8 release manager just went on PTO for a few days... 00:11:39 He just decided to delay it a few days instead of having someone else take it over 00:12:02 Ok 00:12:14 So Jake is involved a bit in the certification program 00:12:42 He's pointed out that a few of the modules that are on the list for certification currently still have missing or disabled tests 00:13:00 This was one of the bigger problem ones: https://github.com/ansible/ansible/issues/54155 00:13:58 We also probably need tests to exercise azure_rm_resourcegroup, but they'd have to be tagged off for CI due to privileges (similar to what happened with rediscache and other long-running ones, but for a different reason) 00:14:45 mattclay: are you lurking? 00:14:48 You mean delicated resource group test? 00:14:51 yes 00:15:03 Ok 00:15:32 Jake was just finishing at a meetup- not sure if he's back in here yet. Jake- anything you want to add/clarify there? 00:15:36 in general we could assume that resource group is tested by the framework, right? 00:15:49 I don't think it uses the module 00:16:22 If we add more test or fix test for these modules in devel, should they backport to stable 2.8? 00:16:30 Ideally, yes 00:16:55 so long as they're test additions/cleanups or bugfixes (not new features of course) 00:17:04 Ok. 00:17:18 maybe if some tests are too long, we coudl at least have check mode tested... 00:17:28 we try and backport test fixes to all supported versions unless that isn't feasible 00:17:39 That would be ideal- at least something that's actually running the module, even if most of it is skipped in CI 00:17:40 i.e. it adds a new module arg or is a big code change 00:18:06 sorry, I am juggling some things here. my apologies. resourcegroup and managed_disk were the only things that came up that need coverage either fixed or added 00:18:41 Ok 00:18:43 _catches up_ you hit everything there Matt 00:19:15 We will look at them and add/fix tests 00:19:19 Cool, thanks! 00:19:28 awesome! thank you! 00:19:32 I think that's all from our side this week- anything else for today? 00:19:52 I m ok 00:21:31 OK, if nothing else, I'll wrap it up in 5.. 00:21:35 4.. 00:21:39 3.. 00:21:42 2.. 00:21:44 1.. 00:21:49 Thanks all- until next week! 00:21:50 Thanks all! 00:21:53 #endmeeting