20:00:03 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:03 <zodbot> Meeting started Tue Jul 17 20:00:03 2018 UTC.
20:00:03 <zodbot> This meeting is logged and archived in a public location.
20:00:03 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:03 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:21 <jhawkesworth_> hey
20:00:27 <nitzmahone> #chair jborean93 dag jhawkesworth_
20:00:27 <zodbot> Current chairs: dag jborean93 jhawkesworth_ nitzmahone
20:01:06 <nitzmahone> Good $time_based_salutation_in_your_region
20:01:30 <jhawkesworth_> you too
20:02:38 <dag> o/
20:03:01 <dag> I wanted to bring something up, but forgot to put it on the agenda
20:03:10 <nitzmahone> Looks like only one item on the agenda- dag's surveying about hiding old stuff on the agendas
20:03:25 <nitzmahone> #topic hiding old stuff on the agenda
20:03:34 <nitzmahone> When you say "hide", do you mean "delete"?
20:03:42 <dag> no, hide the comments
20:03:49 <dag> people can still look at them, and they can be unhid
20:04:02 <dag> (only members can hide/unhide)
20:04:06 <nitzmahone> WFM
20:04:21 <jhawkesworth_> It would be nice to put something in the first comment to say that closed items will get hidden, but otherwise I'm happy with this
20:04:37 * nitzmahone tests to see what a hidden comment looks like
20:04:52 <dag> I think this could be a viable way to extend the lifetime of one agenda (to keep collaborators around longer) and something to reuse for the core agenda at some point in the future
20:04:59 <dag> I hid a few comments at the top
20:05:10 <nitzmahone> Yeah, I like it
20:05:11 <dag> you have to provide a reason for hiding a comment
20:05:30 <dag> but in this case either Outdated or Resolved seem reasonable
20:05:55 <dag> sometimes Offtopic, for stuff that's irrelevant for the agenda (but still added to get some discussion going ;-))
20:06:38 <dag> We can then remove the date from the issue subject too (and no need to update the title, which also makes the agenda cleaner over time)
20:06:40 <nitzmahone> We'll probably still want to bounce to a new agenda (maybe yearly or half-yearly), but this would definitely cut down on the amount of "noise" to search thorough
20:06:49 <dag> and only rename when we do move over to a new agenda
20:06:53 <nitzmahone> yep
20:06:55 <dag> yes
20:07:20 <nitzmahone> #agreed preserve agenda issue lifetime by hiding resolved/outdated comments
20:07:35 <dag> I also wouldn't hide it too soon, I propose after one month (e.g. one month after it was last updated)
20:08:02 <nitzmahone> Sure- that should be a reasonable balance (lets people see the resolution on their own stuff or things they cared about)
20:08:22 <dag> Now for something more controversial
20:08:27 <dag> -> https://github.com/ansible/ansible/pull/42853
20:08:42 <dag> you know me, why have 5 PRs if you can squeeze it into one...
20:09:05 <dag> but I hope this is all sensible stuff (and if not I am happy to revert/change)
20:09:10 <jhawkesworth_> wow that's a monster!
20:09:21 <dag> if you look at the changes, it's actually not
20:09:28 <dag> just a lot of files
20:10:11 <nitzmahone> I'm +1 for all of that, though there may be doc builder/validator implications to the type stuff
20:10:59 <dag> nitzmahone: the type-related changes are actually in accordance to recently changes to the module validator/module doc builder
20:11:02 <jborean93> hey, sorry I'm late
20:11:29 <jhawkesworth_> hey jborean93
20:11:31 <dag> nitzmahone: we don't validate modules with powershell as done with python, but the doc changes conform to new wishes
20:11:32 <nitzmahone> I'm +1 for exposing all types in docs, but that one's probably one for the larger group
20:11:54 <jborean93> I believe that was discussed a few weeks ago and gundalow made the PR to expose that info
20:12:04 <jhawkesworth_> I like knowing types.
20:12:07 <nitzmahone> Also +1 for deprecating WANT_JSON/POWERSHELL_COMMON, and I'd be fine with deprecating them in 2.7
20:12:29 <jborean93> yep +1 for me as well
20:12:31 <nitzmahone> ... same for the old Get-Attr stuff
20:12:32 <dag> the only problem here is that we don't add string-types, as they are the default
20:12:44 <jborean93> I thought "raw" was default?
20:12:58 <nitzmahone> IIRC raw used to be the default
20:13:07 <nitzmahone> But I think that changed ~ 2.2
20:13:12 <jborean93> in PS as well?
20:13:16 <dag> but we can't assume missing types to be string (it's too early, most modules don't have any type-information in the docs)
20:13:32 <jborean93> IIRC if you don't specify `-type` it gives you the de-serialised json?
20:14:13 <nitzmahone> Oh, yeah, I think that's true for the PS side (so yeah, effectively `raw`)- I just meant the basic.py side.
20:14:45 <jborean93> cool
20:14:52 <dag> bcoca preferred not adding "type: str" to all remaining parameters for the python modules
20:14:59 <dag> This is also coming: https://github.com/ansible/ansible/pull/42888
20:15:23 <dag> as we need to better differentiate between required-property and type
20:15:41 <dag> but if there's a better idea of doing that, I like to hear it
20:16:17 <bcoca> type does not need to be red
20:16:44 <bcoca> small/black/grey should be fine
20:16:51 <nitzmahone> IMO: I'd still prefer something inline than the ** thing
20:17:08 <dag> bcoca: true, but if there's also an added_version string for the parameter you get 3 lines and whitespace, becomes too much information for that cell
20:17:14 <nitzmahone> `int, optional`, `string, required`
20:17:20 <dag> added_version is darkgreen
20:17:20 <bcoca> a column?
20:17:28 <nitzmahone> nooo more columns
20:17:30 <jhawkesworth_> I like that but I would also not use red, for accessibility.  I read somewhere there are surprising number of people with difficulty percieiving reds
20:17:38 <nitzmahone> o/
20:17:39 <dag> bcoca: we reduced the number of columns ;-)
20:17:46 <jborean93> yea I prefer required be in the cell and not an asterik
20:17:57 <dag> well, type was red for results already
20:18:00 <bcoca> might be better discussion with our new 'official' docs person
20:18:06 <dag> so I guess that's why they reused it likes this for parameters
20:18:29 <dag> bcoca: sure, that's the plan, but no feedback yet
20:18:35 <dag> acozine, right ?
20:18:38 <bcoca> yep
20:18:59 <dag> jborean93: ok, add a comment to the PR, I can make some new screenshots
20:19:02 <jborean93> she has a few PRs on her plate right now, lots of catching up to do
20:19:26 <dag> anyway, back to PR
20:19:38 <dag> https://github.com/ansible/ansible/pull/42853
20:19:45 <nitzmahone> But so long as adding types to the docs isn't going to screw anything else up, let's get that one merged before it rots :)
20:19:55 <bcoca> maybe put it in 'choices' column, type/choices (with  smaller 'defaults' underneath in blue?)
20:20:25 <dag> bcoca: add it as a comment, I can try that too
20:20:55 <jborean93> I'm happy for `# This file is part of Ansible` to be removed unless we have it there for a reason
20:21:01 <dag> before we merge, look at the 2 test-changes I made at the very bottom of the diff
20:21:24 <bcoca> just make the required ones red?
20:21:33 <bcoca> isntead of **
20:21:44 <dag> bcoca: I think that's more confusing, but add it to the comments
20:22:03 <nitzmahone> Also +1 to ditching the "This file is part of Ansible" stuff - it's not in our standard preamble anymore
20:22:09 <bcoca> just throwing spaguetti at this poit
20:22:13 <sdexter> Hey all, is there a way with win_acl to remove all inherhited permissions?
20:22:50 <bcoca> name(type)
20:22:59 <jborean93> https://github.com/ansible/ansible/pull/42853/files#diff-88d8907ddd92cd5076161b3e2e201cf8L284 <= we run this in CI?
20:23:17 <jborean93> I thought I disabled it due to the stability issues of async on our cloud hosts?
20:23:22 <dag> nitzmahone: ah, thanks for the confirmation ! I noticed 700+ files still had it, but only a very select number of modules (network, cloud mostly) so it's because of copying
20:23:37 <nitzmahone> bcoca: I assume you're good with adding types other than `bool` to the docs then? (so long as the `string` default is still valid and doesn't require us to specify it everywhere)
20:23:58 <bcoca> im fine with adding string, i just thought the 'rule' was DONT add stuff that is default
20:24:03 <dag> jborean93: yeah, it consistently returned wait_attempts = 2
20:24:05 <nitzmahone> Agreed
20:24:11 * bcoca remembers many purges of required=false
20:24:16 <nitzmahone> bcoca: yeah, we definitely don't want to do that
20:24:20 <dag> jborean93: the async changes I will undo, as they made no real difference
20:24:31 <jborean93> dag: cool, yea I need to look further into that, won't be an easy fix
20:24:32 <nitzmahone> But previously docs renderer would convert everything to a bool
20:24:54 <bcoca> having only bool seemed strange, either 'no types' or allow all
20:25:00 <bcoca> +1 for the latter
20:25:03 <nitzmahone> yep, I always thought so too
20:25:23 <dag> bcoca: agreed, but on python modules the default is string, so I would prefer we make string the default if we have cleaned it up ?
20:25:24 <bcoca> also brings it into parity with other plugins, which allow all
20:25:36 <nitzmahone> #agreed we like the approach for https://github.com/ansible/ansible/pull/42853, let's get it merged
20:25:45 <bcoca> @dag sounds reasonable
20:25:55 <dag> nitzmahone: let me remove the 2 test-changes for the broken async
20:25:59 <nitzmahone> Yeah, we should make the PS default string as well
20:26:25 * bcoca thinks we should now have page that explains 'types'
20:26:27 <jborean93> nitzmahone: preferably in a separate PR
20:26:31 <nitzmahone> dag: yeah, want to make sure we're passing as many tests as possible before hitting merge on that one, but I feel pretty good about it
20:26:37 <bcoca> mostly path and json
20:26:42 <nitzmahone> jborean93: yeah, def do those in a separate PR
20:26:54 <bcoca> agreed, no need to burden this one
20:27:07 <dag> ok so I removed the last 2 commits
20:27:44 <dag> also, this shouldn't change any history, except the reduced license statement
20:28:01 <dag> great to hear it's not that controversial :-P
20:28:24 <jborean93> we can make controversial if you like :)
20:28:35 <nitzmahone> Nah- the number of custom Powershell modules doing things "the old way" should be very low, so I'm happy to start down the path of getting rid of that stuff
20:28:50 <jborean93> Given a few version overlaps for people to migrate across
20:28:54 <nitzmahone> yep
20:28:59 <dag> I want to do another cleanup PR removing all use of Get-Attr (and deprecating it)
20:29:03 <nitzmahone> (hypothetical people)
20:29:10 <nitzmahone> dag: also +1
20:29:14 <jborean93> there are dozens of us, dozens!
20:29:41 <dag> only 3 modules using Get-Attr
20:29:55 <nitzmahone> (and Set-Attr IMO)
20:29:57 <dag> lib/ansible/modules/windows/win_acl.ps1
20:29:57 <dag> lib/ansible/modules/windows/win_iis_virtualdirectory.ps1
20:29:58 <dag> lib/ansible/modules/windows/win_iis_website.ps1
20:30:17 <jborean93> what a surprise, IIS again
20:30:20 <nitzmahone> Oh good, those are already all gone
20:30:30 <nitzmahone> But should include in the deprecation
20:30:31 <dag> and maybe one more controversial PR: make all modules use $result for return info
20:30:48 <nitzmahone> That one I'm a little less enthused about
20:31:01 <jborean93> yea, it's not like we do anything special with that variable name
20:31:06 <nitzmahone> a) it's not something we can/should enforce programmatically
20:31:15 <nitzmahone> b) that's pushing a lot more into personal style
20:31:54 <dag> I think there was only one module not using $result
20:32:02 <dag> that's why
20:32:14 <dag> let me check
20:32:26 <nitzmahone> If there's only one, I'm ok with changing it so long as it's not a major attribution loss
20:32:36 <nitzmahone> But if there's a bunch, meh
20:33:23 <dag> these I didn't consider: async_status, win_command, win_shell
20:33:28 <nitzmahone> It's a nice convention (and hopefully one people will pick up on by looking at the other modules), but I don't think it's something we need to enforce rigidly
20:33:52 <dag> hmmm, all of them seem to use $result apart from those
20:34:08 <dag> and those predate any "convention"
20:34:15 <nitzmahone> win_command/win_shell do....
20:34:32 <dag> (I wonder which on I encountered before then...)
20:34:49 <jborean93> my bet is an IIS one that has been refactored
20:35:12 <dag> indeed
20:35:16 <nitzmahone> async_status was a direct port of the Python one (which uses `data`)
20:35:24 <nitzmahone> But I have no problem with it being updated
20:35:28 <dag> ok, skip that idea
20:35:34 <dag> not needed
20:35:55 <dag> the Windows modules or a consistent bunch
20:35:58 <dag> are
20:36:26 <jhawkesworth_> thanks for making them more so
20:36:29 <nitzmahone> #topic open floor (mind the gap)
20:36:46 <jborean93> Once the copyright stuff is in, would be nice to have a sanity check to enforce that standard
20:37:01 <jborean93> I suppose that would be hard considering they all won't be copyrighted to Ansible Project
20:37:03 <nitzmahone> https://www.powercallsirens.com/media/catalog/product/cache/c687aa7517cf01e65c009f6943c2b1e9/o/p/openfloor.jpg
20:37:25 <jborean93> just need a picture of your toilet with the floors ripped up
20:37:42 <nitzmahone> Yeah, that's just something we have to do manually when we're polishing up new modules
20:37:49 <dag> the current agenda has some old comments unhidden ;-)
20:37:56 <dag> I was wondering if we plan to do something with those
20:37:59 <jborean93> Just an FYI, I've been working on a lot of Chocolatey stuff recently
20:38:12 <dag> \o/
20:38:17 <nitzmahone> jborean93: Are you angling to go to choco-con?
20:38:18 <jborean93> have a role to install Chocolatey Server
20:38:32 <jborean93> nitzmahone: not sure, if it is an option then maybe :)
20:38:41 <jborean93> weren't you going?
20:39:07 <nitzmahone> Rob asked me to submit a talk- I figured I'd incorporate some of the fun you've been working on if you weren't going to
20:39:36 <jborean93> would be surprised if I can get approval, will discuss offline though
20:40:52 <dag> https://github.com/ansible/community/issues/294#issuecomment-356972287
20:40:52 <dag> https://github.com/ansible/community/issues/294#issuecomment-356972776
20:40:52 <dag> https://github.com/ansible/community/issues/294#issuecomment-361284337
20:40:52 <dag> https://github.com/ansible/community/issues/294#issuecomment-370898843
20:40:52 <dag> https://github.com/ansible/community/issues/294#issuecomment-384062697
20:41:17 <dag> yeah, we should be going, would be nice to show off Ansible to a Windows wonf
20:41:18 <dag> conf
20:41:48 <jborean93> Thinking about the last comment, maybe we should switch either our 2012 R2 or 2016 to use the core edition
20:42:10 <jborean93> Would help pick up some issues where someone might rely on some shell components that aren't available
20:42:12 <nitzmahone> We talked about adding one of the semiannual channel editions, which would be core only
20:42:13 <dag> https://chocolateyfest.com/
20:42:27 <nitzmahone> That's probably the way to go IMO
20:42:48 <jborean93> need to talk to mattclay about testing the psrp stuff as well
20:42:55 <jborean93> so might bring it up with him at the same time
20:43:08 <nitzmahone> There will almost certainly be tests that will need to be conditionally disabled on core as they have no hope of working
20:43:17 <dag> Meet other folks focused in Windows automation and some of the exciting things they are working on. Windows automation is at a really exciting turning point and you are right in the middle of it!It’s likely you will hear talks and be involved in discussions featuring technologies such as
20:43:17 <dag> Vagrant, Docker, Puppet, Chef, Azure, AWS, Ansible, PowerShell, and others.
20:43:35 <nitzmahone> `*scheduled to appear` ;)
20:44:09 <dag> :-)
20:44:44 <nitzmahone> Just lol'ing at the hedge there "it's likely you will"- reminds me of the "scheduled to appear" hedge they put in the fine print on all the entertainment award shows.
20:45:27 <jborean93> just like Robert Downey Jr is scheduled to appear at each of my birthdays
20:45:30 <nitzmahone> Testing psrp should just be a matter of duplicating the test_winrm stuff, since it's the same transport
20:46:01 <nitzmahone> (eg no special needs from the ansible-test side)
20:46:03 <jborean93> yea, I was really interested whether we want to take over an existing node, e.g. use 2012 with psrp or add a brand new one
20:46:11 <nitzmahone> ah
20:46:43 <nitzmahone> Could go either way; that would probably require some tweaks to ansible-test's and/or CI's inventory generation
20:46:46 <jborean93> would require some conditional checks, I think some raw/script tests may fail due to the output issues but the rest "should" be ok
20:47:05 <jborean93> yep, just something I needed to follow up before merging that PR
20:47:48 <nitzmahone> #action jborean93 to hassle mattclay about more granular per-endpoint config in CI (psrp, authtype, etc)
20:48:06 <nitzmahone> We'll be at OSCON together tomorrow/Thursday, so I can poke him too if I remember
20:48:16 <jborean93> sounds good
20:48:23 <dag> Does everyone agree we don't need this anymore ? (Or should we keep it to forward people to it)
20:48:29 <dag> https://github.com/ansible/community/wiki/Windows:-documentation
20:48:30 <nitzmahone> We'll have 4 nice long car rides in crappy Portland traffic the next 2 days
20:48:41 <jborean93> hopefully long rides in the Tesla
20:48:47 <dag> hehe
20:48:55 <dag> is that still a thing ? :P
20:48:56 <nitzmahone> Autopilot FTW
20:49:04 <jborean93> dag: I don't think it is needed
20:49:07 <nitzmahone> agreed
20:49:15 <jhawkesworth_> yeah, don't need that page any more
20:49:37 <jhawkesworth_> was handy for working up the stuff that is in the windows guides though
20:50:01 <jhawkesworth_> can allways make another if there's suddenly another topic that needs tackling
20:50:19 <nitzmahone> yep
20:50:32 <dag> so there's more stale stuff in the Wiki, and we're thin on future roadmap
20:50:36 <jhawkesworth_> zowie.  Teslas eh.  I am in the wrong job :-)
20:50:48 <nitzmahone> the "cheap" Tesla ;)
20:50:59 <dag> it would be nice to list things like the upcoming chocolatey stuff, etc.
20:51:31 <dag> and maybe finish some of the module cleanup that's still open (or maybe ditch that)
20:52:11 <dag> shall we discuss those in a subsequent meeting ?
20:52:16 <jborean93> if there are still stuff outstanding then we should keep it
20:52:29 <dag> there's nice stuff in there, like: Windows coverage support (mattclay)
20:52:51 <jborean93> maybe convert some of the todo stuff to feature requests on GH
20:53:54 <jborean93> unless we don't want to overload the issue list (arguably already is)
20:54:59 <nitzmahone> Keeping the list as basically a backlog (with links to GH feature requests/issues) would be good
20:55:15 <nitzmahone> That's the way the roadmap stuff will be going forward (every item has to link to a project/issue/PR)
20:55:39 <dag> I think as long as it's not concrete, it shouldn't go into an issue
20:55:40 <nitzmahone> So detail doesn't need to be in the list, but I think it'd be good to keep that around
20:55:49 <nitzmahone> issue == feature request
20:55:56 <nitzmahone> Makes it easier to discuss though
20:55:57 <dag> but if there's an issue we should link it (the SSH on Windows was a future idea ;-))
20:56:21 <dag> nitzmahone: true
20:56:35 <dag> I'll clean it up
20:56:40 <nitzmahone> Esp if people want to +1 it or poke holes in it
20:56:55 <dag> is the official Ansible Windows roadmap known ?
20:57:08 <dag> for 2.7
20:57:27 <nitzmahone> It's pretty light again this time around- mostly bringing in a bunch of stuff Jordan's been background-working on
20:57:46 <nitzmahone> https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_7.rst
20:58:05 <nitzmahone> Potentially a couple big perf things
20:58:20 <nitzmahone> (if we can repro and solve the SChannel/OpenSSL wedging thing)
20:58:29 <dag> how is threading support coming along ?
20:58:50 <nitzmahone> Jimi's still playing with it
20:59:22 <nitzmahone> He wants to get it merged for 2.7 as an experimental option, but we've been kicking around other options for that as well
20:59:39 <jhawkesworth_> last time I tried it couldn't handle kerberos auth, so I didn't manage to get anything to run
20:59:42 <jhawkesworth_> but that was a while ago
21:00:07 <jborean93> there's probably a lot of stuff that won't work, once out there we can hopefully tick a few boxes off
21:00:15 <nitzmahone> (eg, publishing experimental releases from features branches to PyPI like ansible==2.8+threading.dev0)
21:00:45 <nitzmahone> Kerberos should work fine on the threading branch, just not the autokerb
21:00:53 <dag> should we go over the open issues/features and select the ones to finish by v2.7 ?
21:01:00 <jhawkesworth_> yeah it was autokerb iirc
21:01:17 <it-praktyk[m]> Hi, I would like ask what is it preferred way to update existing module?
21:01:40 <it-praktyk[m]> Means I would like add additional options for the win_psmodule
21:02:08 <dag> it-praktyk[m]: I hope you didn't mix up timezones ;-)
21:02:09 <it-praktyk[m]> Can I prepare PR directly to to the Ansible/Ansible repository?
21:02:09 <jborean93> it-praktyk[m]: open a PR with the changes, having tests makes it a lot easier for us to validate and speed up the review process
21:02:15 <nitzmahone> So long as whatever UI changes you make are backwards-compatible, just create a PR
21:02:46 <nitzmahone> If it something you think there might be questions/controversy on, this meeting is a good place to bring it up
21:03:13 <nitzmahone> (add a comment to agenda: https://github.com/ansible/community/issues/294)
21:03:22 <it-praktyk[m]> I live outside of time - this week my timezone is different 😆
21:04:32 <it-praktyk[m]> I would like add options to MinVersion, MaxVersion, Force (to update modules delivered with OS'es)
21:05:17 <jhawkesworth_> they sound like useful options
21:05:41 <nitzmahone> We try to discourage creating new generically-named options like "Force" though
21:05:45 <dag> jborean93: FYI https://app.shippable.com/github/ansible/ansible/runs/74666/11/console
21:05:50 <nitzmahone> Be specific with the name- what are you forcing?
21:06:02 <dag> that's why I did: wait_for_port_already_stopped.wait_attempts >= 1
21:06:33 <it-praktyk[m]> OK, a good point
21:06:44 <jborean93> dag: cool, not surprising considering it uses async to stop the port
21:07:09 <jborean93> nitzmahone: agree, funnily enough the cmdlet uses `-Force` :)
21:07:10 <dag> jborean93: but I removed that test now, so you may want to put that back in ?
21:07:14 <jhawkesworth_> good to catch up, but I gotta go.  catch you next time
21:07:26 * jhawkesworth_ afk
21:07:28 <jborean93> cya
21:07:32 <jborean93> dag: sure
21:07:33 <dag> bye jon !
21:07:46 <dag> s/test/patch
21:08:33 <dag> nitzmahone: https://github.com/ansible/ansible/pull/42853 CI is ready, failed because of known issues
21:09:32 * nitzmahone reviews
21:12:07 <nitzmahone> Not necessarily something we need to address in this PR, but as far as docs go `type: list` should probably be `type: list of [thing]`
21:13:00 <nitzmahone> basic.py has limited support for that (it support list of choice and list of dict-with-suboptions today)
21:13:32 <jborean93> that was something I was hoping to add with a new basic.psm1 or something like that
21:16:04 <dag> nitzmahone: true
21:16:55 <dag> nitzmahone: I don't know who added exposing the type, I just noticed it was done recently (only showing type: bool)
21:17:24 <dag> another cosmetic change I would like to do is translate: bool -> boolean, str -> string, int -> integer
21:17:33 <nitzmahone> That's been there for a really long time (since at least 2.0 IIRC), but yeah, it only shows bool
21:17:46 <dag> now it's a mix of things (different between parameters and result values)
21:18:04 <dag> nitzmahone: yeah, but before recently it wasn't exposed in the module docs
21:18:30 <nitzmahone> can see that one going either way- consistency between the impl and the docs has appeal as well
21:18:43 <dag> https://docs.ansible.com/ansible/2.5/modules/aci_tenant_module.html vs https://docs.ansible.com/ansible/devel/modules/aci_tenant_module.html
21:19:24 <nitzmahone> Oh, I might be thinking of the `required` conversion to bool
21:19:41 <dag> nitzmahone: I would prefer consistency between parameters and result values too, which means updating hundreds of modules, so making docs consistent is easier :-/
21:21:16 <nitzmahone> Anything else pressing for today? We're 20m over ATM...
21:21:24 <jborean93> I'm good
21:21:27 <dag> nah, close the meeting
21:21:59 <nitzmahone> dag- I'm about halfway through the PR review, will hit merge if there's nothing I see that needs tweakage
21:22:07 <nitzmahone> thanks!
21:22:11 <nitzmahone> #endmeeting