00:01:14 <jborean93> #startmeeting Ansible Azure Working Group
00:01:14 <zodbot> Meeting started Thu Apr 11 00:01:14 2019 UTC.
00:01:14 <zodbot> This meeting is logged and archived in a public location.
00:01:14 <zodbot> The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:01:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
00:01:14 <zodbot> The meeting name has been set to 'ansible_azure_working_group'
00:01:23 <yungezz> Welcome
00:01:30 <jborean93> Hello and welcome
00:01:36 <yuwei> welcome PC
00:01:40 <zikalino826544> hi all
00:01:46 <PC> Thanks.
00:01:52 <jborean93> #chair yungezz yuwei zikalino826544 PC
00:01:52 <zodbot> Current chairs: PC jborean93 yungezz yuwei zikalino826544
00:02:21 <yungezz> I have one topic today, about certified module
00:02:35 <yungezz> Will Matt join today?
00:02:46 <jborean93> Just checking now
00:02:55 <yungezz> Thanks
00:03:39 <jborean93> #chair nitzmahone
00:03:39 <zodbot> Current chairs: PC jborean93 nitzmahone yungezz yuwei zikalino826544
00:03:52 <nitzmahone> 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 <yungezz> Hello Matt
00:04:52 <nitzmahone> Go ahead Catherine- I have a couple PRs to ask about, but let's do your topic first
00:04:57 <yungezz> About certified modules, we updated modules based on list and comments in the excel previously
00:05:25 <yungezz> Are those modules ok to be certified? Any other thing need to be done?
00:06:07 <nitzmahone> 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 <nitzmahone> I think most of my concerns had been addressed with the level of validation we have today
00:06:39 <yungezz> Ok. MICROSOFT pm who driving this thing with red hat checking on readiness, code level
00:06:46 <yungezz> Great
00:07:21 <yungezz> That’s my only topic today
00:07:36 <nitzmahone> OK
00:07:38 <yungezz> Again, is there plan on 2.9 so far?
00:08:01 <nitzmahone> 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 <yungezz> Oh, why this one longer?
00:08:33 <yungezz> I mean longer than 3 month
00:08:50 <nitzmahone> The primary driver of the short release cycle is module features, not engine features
00:09:10 <yungezz> Got it, thanks for sharing
00:09:17 <nitzmahone> Now that collections are becoming available, we're hoping most new module development will happen there instead of in the core
00:09:32 <nitzmahone> (thus people can release module updates anytime they want)
00:10:01 <yungezz> Oh , collection will be in 2.9?
00:10:04 <zikalino826544> so when shoudl we move to collection?
00:10:13 <zikalino826544> they are in 2.8 already right?
00:10:28 <yungezz> Be ready
00:10:48 <nitzmahone> 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 <nitzmahone> Yeah, collection support is available (experimental) in 2.8- docs and galaxy tooling will follow after 2.8 GA
00:12:01 <zikalino826544> ok, cool :-)
00:12:08 <yungezz> If we want to create our collection in 2.9, will there be doc or sample for reference?
00:12:15 <zikalino826544> maybe we could start with some new modules
00:12:16 <nitzmahone> There will, but not yet
00:12:22 <yungezz> Got it
00:12:54 <nitzmahone> 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 <yungezz> Great thanks
00:13:43 <zikalino826544> i think we dont' need to hurry
00:13:44 <nitzmahone> 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 <nitzmahone> But will be a good test of the whole thing to make sure I did it right ;)
00:15:02 <nitzmahone> Oh, I had questions on a couple PRs
00:15:14 <yungezz> 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 <yungezz> Pls Matt
00:15:35 <nitzmahone> 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 <nitzmahone> (I'm fine either way)
00:16:12 <zikalino826544> there's equivalent pr from contributor, just a sec
00:16:16 <zikalino826544> he pushed my changes there
00:16:32 <nitzmahone> Oh cool, so we should close 53622 and merge that one then?
00:17:37 <zikalino826544> this one: https://github.com/ansible/ansible/pull/44411
00:17:52 <zikalino826544> yes, i closed 53622 and this one has the same changes now
00:18:06 <nitzmahone> Cool, I'll give a final once over and merge- thanks
00:18:20 <nitzmahone> and then the other one
00:18:46 <nitzmahone> 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 <nitzmahone> IIUC the underlying API doesn't support "None", so that's still broken
00:19:11 <zikalino826544> yeah, the other one unfortunately has failing ci.... and some other problems....
00:19:22 <nitzmahone> OK, so not gonna make 2.8 probably then
00:19:41 <zikalino826544> seems like....
00:20:17 <nitzmahone> OK. Any other last-minute feature things for 2.8, or are we good to go once I merge 44411?
00:20:25 <zikalino826544> seems rebasing gone wrong, and contributor abandoned it
00:20:29 <nitzmahone> doh
00:20:50 <zikalino826544> 42400 :-)
00:21:48 <nitzmahone> That was the one with the broken "None"
00:22:09 <nitzmahone> https://github.com/ansible/ansible/pull/42400/files#r267594472
00:22:21 <zikalino826544> oh, sorry... i am mixing up things....
00:23:26 <nitzmahone> Should be a pretty easy fix, but I had other things to work on
00:24:31 <nitzmahone> 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 <zikalino826544> ah, this one, i think i can fix it (should have access) and then merge it
00:25:15 <nitzmahone> 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 <zikalino826544> ok
00:26:07 <yungezz> 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 <nitzmahone> 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 <nitzmahone> I think I filed a bug about that blocking behavior while I was organizing the tests
00:29:07 <nitzmahone> Since IIRC that one is new for 2.8, it should probably get changed before GA if possible
00:29:22 <yungezz> Default to let user wait? I think let user explicitly asking for wait
00:29:44 <yungezz> Yes I have a Pr for it ready, will update name later
00:29:45 <nitzmahone> The module's not very usable otherwise- the user would have to poll manually
00:30:14 <nitzmahone> 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 <yungezz> User just set the argument to true, with the new argument
00:30:43 <nitzmahone> 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 <yungezz> My thought is user could parallel doing some other tasks
00:32:15 <nitzmahone> 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 <yungezz> That make sense
00:32:44 <nitzmahone> 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 <yungezz> Otherwise user even don’t know they need poll wait
00:33:08 <nitzmahone> exactly
00:33:27 <yungezz> Ok I will update default to true
00:33:30 <nitzmahone> Most people don't read the docs, so it should match the expectation set by other modules
00:33:51 <yuwei> I have one question about galaxy role’s tasks
00:34:10 <nitzmahone> sure
00:34:14 <yuwei> 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 <yuwei> I am wondering what is the best practice to support the dry-run in role
00:35:40 <nitzmahone> 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 <nitzmahone> 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 <nitzmahone> So maybe having well-known check-mode sentinel values across all the Azure modules would be a good thing.
00:37:34 <nitzmahone> 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 <nitzmahone> (when running in check mode itself)
00:38:13 <nitzmahone> Make sense?
00:38:39 <yuwei> Sounds like a big work in our current modules
00:39:08 <yuwei> And some attribute besides the I’d
00:39:12 <nitzmahone> Yeah, check mode is often difficult in large automation
00:39:29 <yuwei> besides the id may be set by service
00:39:53 <yuwei> According to the assumption we need to handle these as well
00:39:56 <nitzmahone> Well, in check mode (at least for "I need to create this" case) the entire result is synthetic
00:41:17 <nitzmahone> Ideally the result "shape" would be the same for check-mode and not
00:41:32 <nitzmahone> But as you say, we're far from there today :)
00:42:09 <yuwei> I see. I used to think we can manage it in playbook task level
00:42:47 <nitzmahone> You can; either conditionally skip downstream tasks, or use `| default(omit)` on problematic arguments
00:43:42 <nitzmahone> (using `ansible_check_mode` var to skip tasks or conditionally omit problem args)
00:44:13 <nitzmahone> 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 <yuwei> Yes
00:45:02 <jborean93> 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 <nitzmahone> 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 <nitzmahone> OK, anything else for today?
00:46:29 <yuwei> No from me, thanks
00:46:36 <yungezz> No from me
00:46:45 <yungezz> Thanks all!
00:47:46 <nitzmahone> Great- until next week! Thanks all...
00:47:48 <nitzmahone> #endmeeting