20:00:13 <jborean93> #startmeeting Windows Working Group
20:00:13 <zodbot> Meeting started Tue Jul 18 20:00:13 2017 UTC.  The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:13 <zodbot> The meeting name has been set to 'windows_working_group'
20:00:19 <jhawkesworth_> hey
20:00:20 <jborean93> morning everyone
20:00:47 <dag> perfect evening for having a Windows meeting !
20:00:57 <nitzmahone> It's a loverly afternoon ;)
20:01:01 <dag> hehe
20:01:19 <jhawkesworth_> open windows.  now there's an idea
20:01:21 <dag> with trond even !
20:01:27 <trondhindenes> hola folks!
20:01:40 <jhawkesworth_> heya
20:01:43 <jborean93> #chair dag nitzmahone jhawkesworth_ trondhindenes
20:01:43 <zodbot> Current chairs: dag jborean93 jhawkesworth_ nitzmahone trondhindenes
20:01:50 <nitzmahone> #info https://github.com/ansible/community/issues/195
20:01:51 <dag> not a lot on the agenda, so maybe we can go over some PRs if there's time
20:01:56 <trondhindenes> sorry I've been a bit off the last couple of weeks. Vacation timez
20:01:57 <nitzmahone> WFM
20:02:05 <nitzmahone> Welcome back!
20:02:18 <jborean93> welcome
20:03:07 <jborean93> starting from the topic of the agenda list
20:03:08 * nitzmahone wonders what happens if our startmeeting commands crossed in the ether (I was typing just as jborean93's came in)
20:03:08 <trondhindenes> I have one item I'd like to discuss quickly if time, but we can do that towards the end
20:03:11 <jborean93> #topic https://github.com/ansible/community/issues/195#issuecomment-314705308
20:03:29 <jborean93> I've got nothing to add, just waiting on some review stuff
20:04:10 <nitzmahone> Oh yeah, I was suggesting fixing up the pinvoke stuff to be "docs compliant" WRT passing null instead of an empty struct
20:04:50 <nitzmahone> I can just make/push the changes to that branch, or we can go over it, but I think once you see it you'll understand
20:05:10 <jborean93> I remember trying it out but I was missing some knowledge, might be for the best to push the changes and I'll see how you've done it
20:05:17 <nitzmahone> k
20:05:22 <jborean93> I might even hold off until the module_utils is in and put that stuff there as well
20:05:32 <nitzmahone> #action nitzmahone to push recommended changes to #23119
20:05:33 <jborean93> will be useful for win_stat and win_find
20:05:40 <dag> nitzmahone: merge it and do another PR for review ?
20:06:09 <nitzmahone> Nah, committers can push changes directly into the PR branch
20:06:17 <nitzmahone> (no 2nd PR req'd)
20:07:15 <jborean93> #topic https://github.com/ansible/community/issues/195#issuecomment-314706600 new modules
20:07:17 <dag> ah
20:07:29 <dag> that's weird, because it's someone else's branch
20:07:54 <dag> I've seen the checkbox, but never knew what it really did
20:07:54 <jborean93> dag there is a checkbox that allows others to push to the branch
20:07:57 <nitzmahone> They go into the PR pseudo-branch, not the original- it's github magic
20:08:18 <nitzmahone> (actually can't remember, maybe they do go into the original source branch)
20:08:39 <trondhindenes> win_xml is interesting
20:08:43 <nitzmahone> Lifesaver for dumb PEP8 issues and stuff- easier for us to just fix/merge
20:08:46 <dag> ok, so decide and move on ;-)
20:09:27 <jborean93> I need to look at the changes that have been pushed to win_xml. I admit I have no use as I try and avoid XML where possible but can see where people might want it
20:09:38 <nitzmahone> I think jborean93 has addressed my comments on his PRs, so I'll do a final pass over those and merge
20:10:01 <jborean93> win_certificate is waiting on the author to respond to dag's comments
20:10:01 <nitzmahone> Agreed- better to template where reasonable, but sometimes you gotta work with what's there...
20:10:19 <jborean93> I need to look at win_pagefile
20:10:21 <nitzmahone> #action nitzmahone to final review/merge jborean PRs
20:10:43 <nitzmahone> I coulda sworn that some pagefile changes required reboot (removal, maybe?)
20:10:43 <jborean93> jhawkesworth_ how is the win_toast stuff going?
20:10:45 <jhawkesworth_> ignore win_toast - it doesn't work, probably needs a scheduled task in order to make notifications hang around
20:10:54 <dag> jborean93: for win_xml to me it's important to have it work exactly as the new xml module
20:11:05 <dag> jborean93: so I would hold off until the xml module is merged
20:11:25 <nitzmahone> dag: agreed- ideally we'd run the same test suite on both
20:11:43 <jborean93> no worries, I know the author asked me to check on his latest changes but will definitely hold off from merging
20:11:43 <trondhindenes> yeah. We're gonna need a metric ton of testing on that, given the complexity of xml
20:12:19 <jborean93> XML makes everything great especially when stuff goes off spec and required the elements in a particular order
20:12:28 * jborean93 looking at WinRM PSRP
20:12:33 <nitzmahone> lol
20:12:51 * nitzmahone doesn't miss being an XML expert
20:12:59 <nitzmahone> That stuff is being rapidly paged out
20:13:02 <jhawkesworth_> ouch.  microsoft seem to have weird aversion to xml attributes too.
20:13:21 <jborean93> nitzmahone: thank god I hate XML
20:13:26 <nitzmahone> Yeah, most of their dialects are very element-centric
20:13:59 <jborean93> for win_domain_user I'm happy to take on the stuff as the author still hasn't replied, might give it a few more days but will continue it on if I hear nothing back
20:14:00 <trondhindenes> I spent 5 consecutive days inside IIS's (xml-based) config trying to automate our logging config. I made it work, but I've been seeing a therapist ever since
20:14:01 <nitzmahone> OK, so I'm taking care of Jordan's from that list, we're holding off on xml and toast
20:14:34 <jhawkesworth_> win_domain_group looks good, no cause to try it out at the moment though.
20:14:40 <nitzmahone> Heh, I remember being at the PDC where they first showed XML config of IIS and that you could have a "naked" IIS with no functionality ala Apache
20:14:52 <nitzmahone> There was much applause
20:15:05 * jborean93 wondering if they were forced at gunpoint
20:15:29 <jhawkesworth_> this was before we all discovered what a PITA xml manipulation was I assume?
20:15:40 <jborean93> nitzmahone if you can look at win_group_member as well. I'm pretty happy with it but would be good if you can have a glance before merging
20:15:45 <nitzmahone> Compared to the older ones, it was a big improvement
20:15:58 <nitzmahone> #action nitzmahone to review #26307
20:16:27 <jborean93> #topic https://github.com/ansible/community/issues/195#issuecomment-314707679 tests
20:16:27 <nitzmahone> Yeah, I've glanced over it and in general looked good- I had some similar questions to you around the principal lookup IIRC, but in general looks pretty close
20:16:45 <jborean93> I'm waiting for the module utils to go in for the camel case conversion on the IIS tests
20:17:08 <jborean93> dag probably good to get a consensus on win_unzip and the return values here
20:17:31 <nitzmahone> I can probably hit merge on it right now- though we should discuss a bit. A couple of things I'd like to make sure we're on the same page for when we get to open floor
20:18:03 <nitzmahone> #action nitzmahone to review tests in #25869, 25902, 25335
20:19:09 <jborean93> for the iis stuff, I still need to do the binding but feel I should remove the deprecation on the binding stuff on win_iis_website
20:19:46 <jborean93> Currently it only works when no site exists, I set that to deprecated but feel it should be there in case someone creates a site but the bindings are not unique
20:19:55 * dag is still working on win_robocopy, I got it off the list
20:20:16 <jborean93> we would still recommend people use win_iis_webbindings to modify them but this way at least new sites can be created correctly
20:22:13 <jborean93> For the win_unzip PR, dag has moved the return values outside of result.win_unzip.* to just result.*. Do we want to keep both for x versions and then finally remove or just rip the bandaid off right now
20:22:52 <jhawkesworth_> I vote rip the bandaid off - as long as it goes in the 2.4 migration guide its really easy to fix up your playbooks
20:22:54 <jborean93> This would also affect how the IIS modules set their return values as currently the changes I've made are transitioning from the old way to the new way in my PR
20:23:49 <dag> in this case the module was still in preview
20:24:02 <dag> the CHANGELOG does have the detailed bits
20:24:31 <nitzmahone> I'm fine with hard cut for 2.4 on that one
20:24:42 <jborean93> ok, I'll do one last glance over today before merging
20:25:01 <nitzmahone> #agreed don't keep both output formats for win_unzip
20:25:59 <jborean93> IIRC the win_iis_* stuff is also preview so probably will follow suite
20:26:01 * dag was convinced with renaming 'rm' to 'remove', as there's also the default 'removes' parameter and these are close
20:26:13 <dag> maybe 'purge', 'cleanup', or something like that
20:26:19 * jhawkesworth_ still using a custom win_unzip anyway
20:26:33 <dag> s/convinced/unconvinced/
20:26:59 * dag still contemplates doing a 7zip and win_7zip module :-P
20:27:03 <nitzmahone> yeah, purge would probably be good
20:27:25 <jborean93> delete?
20:28:08 <dag> all fine by me, my only concern with remove is that it's too close to removes
20:28:57 <jborean93> happy with either of the suggestions
20:29:02 <nitzmahone> Slight preference to `purge` over `delete`, but prefer more descriptive like `delete_archive` or `delete_original_archive`
20:30:44 * dag prefers cleanup
20:31:03 <jhawkesworth_> descriptive names are good - I'd vote for 'delete_archive' if there was a vote
20:31:14 <dag> as it indicates it's cleaning up something it created itself
20:31:36 <jborean93> you can say that with any word :)
20:32:01 <jborean93> I probably prefer the more descriptive one like delete_archive as well
20:32:23 <trondhindenes> me too
20:32:32 <dag> alright
20:32:39 <dag> delete_archive
20:32:44 <jborean93> #action dag to change remove to delete_archive on win_unzip
20:33:17 * nitzmahone may or may not have been working ahead on the agenda
20:33:29 <dag> :-)
20:33:33 <jborean93> #topic https://github.com/ansible/community/issues/195#issuecomment-314708475 connection errors
20:33:42 <jborean93> dag did you make any progress with this
20:33:50 <dag> I have a reproducer
20:34:09 <dag> haven't made a PR out of my ugly fix
20:34:36 <dag> (the pretty fix is impossible since requests doesn't return the connection failure reason properly)
20:35:05 <dag> I may have to do string-matching :-/
20:35:12 <nitzmahone> ick
20:35:22 <jborean93> maybe we need to do some downstream changes with requests?
20:35:25 <nitzmahone> Can't remember if you were addressing inside pywinrm or winrm CP?
20:35:37 <dag> pywinrm
20:35:50 <nitzmahone> ok
20:36:33 <dag> but we can skip this topic until I have time for it
20:36:39 <nitzmahone> ok
20:37:05 <jborean93> sounds good
20:37:16 <jborean93> #topic https://github.com/ansible/community/issues/195#issuecomment-315468341 CI changes
20:37:32 <nitzmahone> So with all these new integration tests, Windows CI perf has tanked
20:37:45 <nitzmahone> We knew this would be an issue, and we don't want to turn away the tests
20:37:54 <nitzmahone> So we've changed how often they run
20:38:12 <jborean93> is this for global changes to Windows so they don't run all the tests?
20:38:26 <nitzmahone> It used to be that all Windows module tests would run anytime there was a change to a Windows module utils file, connection plugin, or various other controller code
20:38:55 <nitzmahone> Now, anything that's not in the new windows/ci/smoketest group will only run on changes to that module or its tests.
20:39:40 <jhawkesworth_> any plans to do a periodic full test?
20:39:45 <nitzmahone> Most modules fall into that category. There are diminishing returns to running all the tests on every change, but with the risk that certain changes to module_utils code *might* break a module and we wouldn't know about it until after it was merged
20:40:01 <nitzmahone> The code coverage tests will always  run everything
20:40:06 <jhawkesworth_> k
20:40:22 <nitzmahone> I think those are run once a day (@mattclay?)
20:40:58 <jborean93> as long as we at least have the full coverage being run will help identify those issues
20:40:59 <nitzmahone> So we've done away with the group1/2/3 stuff (we'll will be removing that tag soon from tests)
20:41:31 <jborean93> how do we exclude tests from running, currently win_domain_group has tests but can't run in Shippable
20:41:37 <jborean93> I just didn't include anything in the aliases
20:41:55 <nitzmahone> It's also only running on one Windows instance now, so that will cut down our Windows CI costs (which were quickly approaching $1000/mo)
20:42:06 <nitzmahone> Just don't put anything in aliases
20:42:11 <nitzmahone> yep
20:42:38 <jborean93> ok
20:42:49 <nitzmahone> So changes to a module or its tests will still be run on multiple windows versions
20:42:50 <dag> Hmm, so we're now worse off ? :-/
20:43:10 <nitzmahone> But the "smoke test" stuff when shared code changes will only (for now) be run on 2012R2
20:43:18 <dag> ah ok
20:43:42 <nitzmahone> That'll probably change at some point, but as long as we're paying for AWS for this stuff, we need to keep it within a decent budget
20:43:51 <nitzmahone> (as well as keeping runtimes sane)
20:44:04 * jborean93 was hoping the azure guys could give us free instances
20:44:21 <nitzmahone> The smoke test set will ideally take < 10m to run (not including instance startup), so please don't add things to it without discussing
20:45:01 <nitzmahone> Yeah, I've raised that topic with them many times- something about lead balloons? ;)
20:45:15 <gundalow> Coverage job is ran at 0700UTC
20:45:55 <nitzmahone> There are big-picture changes in the works for CI, some of which will involve Red Hat datacenter resources that we can use, so we'll definitely revisit then, if not sooner.
20:46:11 <nitzmahone> Timing is still Real Soon Now on that
20:46:19 <trondhindenes> btw, any news on a WMF5.1 2012R2 runner?
20:46:28 <trondhindenes> I haz tests itching for a runner :-)
20:46:44 <nitzmahone> Module tests?
20:46:49 <nitzmahone> (DSC, I assume)
20:47:05 <trondhindenes> yup
20:47:49 <nitzmahone> Matt Clay may be at lunch- I think we got a prototype WMF5.1-upgraded 2012R2 setup going once that only added < 1m to the startup, but he might remember better than me.
20:47:51 <trondhindenes> I guess it ties in to the Pink Bandana datacenter you mentioned.
20:47:54 <trondhindenes> Sorry, "Red Hat"
20:47:58 <nitzmahone> lol
20:48:07 <trondhindenes> :-)
20:48:23 <trondhindenes> thanks, nice to know there's progress
20:48:24 <nitzmahone> If we leave 2012 on WMF4, I'm ok doing 2012R2+WMF5.1
20:48:43 <nitzmahone> #action nitzmahone to follow up w/ mattclay on WMF5.1-upgrading 2012R2 runner
20:49:07 <trondhindenes> Ideally we would test 2012R2 with both WMF4 and 5.1 but I totally see the cost thing
20:49:53 <nitzmahone> Well, and individual module tests are arguably cheaper, but I don't know what the split looks like for "all tests" vs "single module tests" off the top of my head
20:50:04 <nitzmahone> Any other questions on the testing changes before we move on?
20:50:12 <jborean93> no I'm ok
20:50:25 <nitzmahone> OK, open floor
20:50:30 <jhawkesworth_> nope, sounds like progress to me
20:50:33 <nitzmahone> #topic open floor
20:51:00 <nitzmahone> FYI, shared module_utils PR is here: https://github.com/ansible/ansible/pull/26932
20:51:21 <trondhindenes> I have a thing:
20:51:24 <nitzmahone> This lets you do #Requires -Module Ansible.ModuleUtils.Whatever to load anything
20:51:48 <nitzmahone> (ala Python) and also allows for role/playbook/userdir/config module_utils for PS
20:51:58 <trondhindenes> nice!
20:52:26 <nitzmahone> With that, I've moved powershell.ps1 to module_utils/powershell/Ansible.ModuleUtils.PowerShellLegacy.psm1
20:52:37 <trondhindenes> it had a good run
20:52:49 <nitzmahone> Anything that uses # POWERSHELL_COMMON or #Requires that will get it
20:53:02 <jborean93> I've got plans to do a util for SID conversion/camel case conversion/symlink helpers
20:53:06 <nitzmahone> First crack at declarative argspec/new PS module API coming soon
20:53:09 <jborean93> once it has been merged in
20:53:17 <dag> My talk about Ansible Windows was accepted for AnsibleFest SFO
20:53:32 <dag> surprised me
20:53:34 <nitzmahone> Waiting for confirmation from mattclay that CI failures are unrelated before merging
20:53:51 <nitzmahone> (there were several direct commits and stale CI merges today that broke stuff all over the place)
20:54:01 <nitzmahone> dag: what was the topic?
20:54:39 <nitzmahone> I'm doing one on module developement, though it was deliberately cagey about covering Windows or not (will have to see how timing on Python dev works out)
20:54:49 <trondhindenes> So my topic: I pinged the group a while back on how to actually do testing while devving locally. Putting on my "I don't know python and I dont care" hat here: There's pretty slim documentation for anyone wanting to submit Powershell modules.
20:54:49 <trondhindenes> And I have to admit, I've not yet been able to run ansible-test locally with any success. Which means that I'm either slow or the documentation is lacking. Reality is probably a bit of both. So: I'd like an action point on ramping up "here's the stuff you need" for Powershell module devs
20:55:12 <trondhindenes> (I'd also like someone to explain to me how to use ansible-test locally since I have yet to get it working)
20:55:20 <nitzmahone> Good call
20:55:28 <nitzmahone> ansible-test does work great with PS stuff
20:55:47 <nitzmahone> Do you have your inventory set up (inventory.winrm in test/integration)?
20:55:54 <dag> nitzmahone: It's about what we do at the elementary school
20:55:59 <mattclay> nitzmahone: CI failure seems related.  I sent you a mes on Slack.
20:56:05 <nitzmahone> k, thx
20:56:21 <mattclay> s/med/message/
20:56:48 <mattclay> Typing on phone. ;)
20:56:56 <jborean93> trondhindenes: I believe we are looking to focus on doc stuff during the engine freeze coming sooon
20:57:01 <trondhindenes> Lets assume I know nothing. I have ansible running against my windows node
20:57:06 <trondhindenes> i dont know what to do from there
20:57:35 <nitzmahone> Fill out the inventory template at test/integration/inventory.winrm.template, rename to inventory.winrm (in same dir)
20:57:45 <trondhindenes> tweet from a dude whoe PRd some changes to win_dsc: "Tnx for merging it! You mentioned testing - any docs I can read about it, I don't mind adding tests TBH... :)"
20:57:55 <nitzmahone> then run `ansible-test windows-integration win_ping` as a sample
20:57:56 <trondhindenes> we need to get that into docs
20:58:02 <trondhindenes> thanks, will try
20:58:31 <trondhindenes> I dont know if that's a "test-sig" or "windows-sig" thing btw - who would own the docs for this stuff
20:59:01 <nitzmahone> Probably both- it's been moving really fast, so docs haven't kept up with code
20:59:14 <nitzmahone> We should have some basics specific to Windows in our dev docs
20:59:15 <jborean93> there is also some docs that cover some of it http://docs.ansible.com/ansible/dev_guide/testing_integration.html#windows-tests but needs to be updated
20:59:22 <dag> trondhindenes: Thanks, I am doing all my tests through Shippable CI, adding up to the $1000/month :-)
20:59:52 * jborean93 will admit to just having my own folder with each role as the tests and running that
21:00:04 <jborean93> need to look at ansible-test more
21:00:10 <nitzmahone> That's just the AWS Windows instances, too- there are lots of other costs that add up :)
21:00:45 <nitzmahone> ansible-test is hella slick- I finally got the autocomplete working in my venv, just makes it that much easier when you can tab through options
21:01:00 <trondhindenes> never seen the integration test doc before. Is it linked from somewhere?
21:01:06 <nitzmahone> We're at the hour- any last minute stuff?
21:01:24 <dag> Please keep the wiki up to date with your stuff :)
21:01:48 <jborean93> trondhindenes I got it from here
21:01:48 <jborean93> http://docs.ansible.com/ansible/dev_guide/index.html
21:01:51 <jborean93> just drilled down
21:01:57 <jborean93> nitzmahone: I'm good
21:02:12 <nitzmahone> trondhindenes: "Developer Information"->Testing Ansible->Integration Tests
21:02:38 <jhawkesworth_> anyone know how to get autocomplete working - I never got it to work in WSL
21:02:44 <trondhindenes> ah. there's "testing your module" and then "testing Ansible"
21:02:56 <trondhindenes> jon: for Ansible or python code in general?
21:03:07 <jhawkesworth_> only tried with ansible-test
21:03:21 <trondhindenes> I'm gonna submit an issue that hopefully gets picked up by the test-sig regarding doc sprawl regarding testing.
21:04:24 <jhawkesworth_> its a good point, trond you'd tend to hit the 'testing your module' stuff first which is not so much help for windows at the moment
21:06:04 <trondhindenes> that's where I've always stopped :-)
21:06:12 <trondhindenes> never saw the "testing ansible" below
21:06:43 <nitzmahone> I gotta run to take the kid to a Dr. appt  - jhawkesworth, hit me up on IRC tomorrow and I'll help you get argcomplete going under WSL
21:06:51 <nitzmahone> Later all!
21:06:53 <jborean93> later
21:06:55 <jborean93> #endmeeting