00:01:14 #startmeeting Ansible Azure Working Group 00:01:14 Meeting started Thu Apr 11 00:01:14 2019 UTC. 00:01:14 This meeting is logged and archived in a public location. 00:01:14 The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:01:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 00:01:14 The meeting name has been set to 'ansible_azure_working_group' 00:01:23 Welcome 00:01:30 Hello and welcome 00:01:36 welcome PC 00:01:40 hi all 00:01:46 Thanks. 00:01:52 #chair yungezz yuwei zikalino826544 PC 00:01:52 Current chairs: PC jborean93 yungezz yuwei zikalino826544 00:02:21 I have one topic today, about certified module 00:02:35 Will Matt join today? 00:02:46 Just checking now 00:02:55 Thanks 00:03:39 #chair nitzmahone 00:03:39 Current chairs: PC jborean93 nitzmahone yungezz yuwei zikalino826544 00:03:52 Hey all, sorry- I need to set my alarm for like 1min before instead of 10, or I get distracted and forget ;) 00:04:02 Hello Matt 00:04:52 Go ahead Catherine- I have a couple PRs to ask about, but let's do your topic first 00:04:57 About certified modules, we updated modules based on list and comments in the excel previously 00:05:25 Are those modules ok to be certified? Any other thing need to be done? 00:06:07 I think nothing for now- other people are actually running the certified program, so they just asked me what I'd want to see and which modules we should do first 00:06:25 I think most of my concerns had been addressed with the level of validation we have today 00:06:39 Ok. MICROSOFT pm who driving this thing with red hat checking on readiness, code level 00:06:46 Great 00:07:21 That’s my only topic today 00:07:36 OK 00:07:38 Again, is there plan on 2.9 so far? 00:08:01 On the Ansible side, we'll probably start planning in the next few weeks, but I think it's a 6-month-ish cycle 00:08:19 Oh, why this one longer? 00:08:33 I mean longer than 3 month 00:08:50 The primary driver of the short release cycle is module features, not engine features 00:09:10 Got it, thanks for sharing 00:09:17 Now that collections are becoming available, we're hoping most new module development will happen there instead of in the core 00:09:32 (thus people can release module updates anytime they want) 00:10:01 Oh , collection will be in 2.9? 00:10:04 so when shoudl we move to collection? 00:10:13 they are in 2.8 already right? 00:10:28 Be ready 00:10:48 We're not getting rid of the stuff "in the box", and if people want to "sync" that for a given release with a collection for stuff that's already there, should be fine, but I think we're going to start making it harder to include new modules in core distribution starting in 2.9 and 2.9++ 00:11:25 Yeah, collection support is available (experimental) in 2.8- docs and galaxy tooling will follow after 2.8 GA 00:12:01 ok, cool :-) 00:12:08 If we want to create our collection in 2.9, will there be doc or sample for reference? 00:12:15 maybe we could start with some new modules 00:12:16 There will, but not yet 00:12:22 Got it 00:12:54 Once 2.8 gets quieter closer to GA, I can take all the existing Azure plugins and package as a collection to show you how 00:13:15 Great thanks 00:13:43 i think we dont' need to hurry 00:13:44 Up to you though when you feel comfortable enough with that to say "here's where we're doing new active development" vs in core as today 00:14:45 But will be a good test of the whole thing to make sure I did it right ;) 00:15:02 Oh, I had questions on a couple PRs 00:15:14 Zim , Sure we’re not hurry up to release it immediately without good planning, while we can start to look at it and try ourselves 00:15:25 Pls Matt 00:15:35 Zim: do you want me to merge https://github.com/ansible/ansible/pull/53622 as-is? There was talk of moving back to another PR or trying to preserve original attribution 00:15:47 (I'm fine either way) 00:16:12 there's equivalent pr from contributor, just a sec 00:16:16 he pushed my changes there 00:16:32 Oh cool, so we should close 53622 and merge that one then? 00:17:37 this one: https://github.com/ansible/ansible/pull/44411 00:17:52 yes, i closed 53622 and this one has the same changes now 00:18:06 Cool, I'll give a final once over and merge- thanks 00:18:20 and then the other one 00:18:46 https://github.com/ansible/ansible/pull/42400 - the license_type is still messed up I think with the "None" string value instead of None Python null 00:19:01 IIUC the underlying API doesn't support "None", so that's still broken 00:19:11 yeah, the other one unfortunately has failing ci.... and some other problems.... 00:19:22 OK, so not gonna make 2.8 probably then 00:19:41 seems like.... 00:20:17 OK. Any other last-minute feature things for 2.8, or are we good to go once I merge 44411? 00:20:25 seems rebasing gone wrong, and contributor abandoned it 00:20:29 doh 00:20:50 42400 :-) 00:21:48 That was the one with the broken "None" 00:22:09 https://github.com/ansible/ansible/pull/42400/files#r267594472 00:22:21 oh, sorry... i am mixing up things.... 00:23:26 Should be a pretty easy fix, but I had other things to work on 00:24:31 Oh, also, I reorg'd the rediscache tests a bit in devel to make the tagging exclusion work right; that module really needs to block by default 00:24:33 ah, this one, i think i can fix it (should have access) and then merge it 00:25:15 Yeah, if you fix the None handling on license_type, I'm otherwise +1 to merge, so go ahead. It needs to be merged within about 8h to make the freeze. 00:26:04 ok 00:26:07 I have a small question on Redis cache waiting for provision (create/update/reboot)completion argument name, is wait_for_completion good ? Other names discussed: wait_for_provisioning, wait_for_running 00:27:51 I like `wait_for_provisioning `, and default it to true. The fast-running tests can set it to false, but the slow ones (now excluded by tags) should wait. I was having some trouble getting those to pass, but check out the way they're organized and using blocks with tags to exclude them in a group. It's a good pattern for other things we can't test in CI but want to be able to test manually without modifying the tests 00:28:31 I think I filed a bug about that blocking behavior while I was organizing the tests 00:29:07 Since IIRC that one is new for 2.8, it should probably get changed before GA if possible 00:29:22 Default to let user wait? I think let user explicitly asking for wait 00:29:44 Yes I have a Pr for it ready, will update name later 00:29:45 The module's not very usable otherwise- the user would have to poll manually 00:30:14 It's slow, but the results of the module run are not usable in any kind of real-world scenario without blocking 00:30:15 User just set the argument to true, with the new argument 00:30:43 Right, but defaulting to not blocking is not useful in nearly any real-world scenario- why not default to the usable case? 00:31:52 My thought is user could parallel doing some other tasks 00:32:15 Everybody knows that resource is slow, it's been complained about for years- nothing we can do about that, but we should make simple orchestration work "out of the box" without someone having to know they have to explicitly block before being able to use it. The expectation is usually that once the module returns, the resource is usable, and this resource doesn't work that way 00:32:44 That make sense 00:32:44 People wanting to do parallelization can explicitly set to false, but that's not the common user's path in my experience. 00:33:02 Otherwise user even don’t know they need poll wait 00:33:08 exactly 00:33:27 Ok I will update default to true 00:33:30 Most people don't read the docs, so it should match the expectation set by other modules 00:33:51 I have one question about galaxy role’s tasks 00:34:10 sure 00:34:14 do you know how to handle dry-run in galaxy role task? For instance, creating a NIC and attach the NIC to a new created VM, but in the check mode, there is nothing created, how can I pass the NIC id to VM in the role 00:35:29 I am wondering what is the best practice to support the dry-run in role 00:35:40 That's one of those things where making check-mode work "in the real world" is hard; either the module should return a bogus or sentinel ID (which can cause problems sometimes) or the receiver needs to know it might be empty and default it to being omitted. It's tricky either way. 00:36:24 If you return a bogus ID, and the VM module consumes it and *its* check mode impl tries to validate, it will still break 00:36:54 So maybe having well-known check-mode sentinel values across all the Azure modules would be a good thing. 00:37:34 So eg if the VM module receives a sentinel value for the NIC ID, it could ensure that the actual validation of it is skipped 00:37:44 (when running in check mode itself) 00:38:13 Make sense? 00:38:39 Sounds like a big work in our current modules 00:39:08 And some attribute besides the I’d 00:39:12 Yeah, check mode is often difficult in large automation 00:39:29 besides the id may be set by service 00:39:53 According to the assumption we need to handle these as well 00:39:56 Well, in check mode (at least for "I need to create this" case) the entire result is synthetic 00:41:17 Ideally the result "shape" would be the same for check-mode and not 00:41:32 But as you say, we're far from there today :) 00:42:09 I see. I used to think we can manage it in playbook task level 00:42:47 You can; either conditionally skip downstream tasks, or use `| default(omit)` on problematic arguments 00:43:42 (using `ansible_check_mode` var to skip tasks or conditionally omit problem args) 00:44:13 But yeah, ideally if the modules work right together (eg sentinel values as discussed), there's a lot less work to do in the playbook 00:44:40 Yes 00:45:02 Typically we do a check mode test for specific scenarios in our test to make sure it reported a change but a change didn’t occur. But as nitzmahone says it can get quite hairy if we return ids for things that don’t actually exist yet 00:45:17 We've had some discussions about how to better get a full "list of things to do" like Terraform has, but that's difficult in practice without having a graph model, which Ansible doesn't (and probably never will) 00:46:16 OK, anything else for today? 00:46:29 No from me, thanks 00:46:36 No from me 00:46:45 Thanks all! 00:47:46 Great- until next week! Thanks all... 00:47:48 #endmeeting