00:00:08 <nitzmahone> #startmeeting Windows Working Group 00:00:08 <zodbot> Meeting started Tue Mar 14 00:00:08 2017 UTC. The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 00:00:08 <zodbot> The meeting name has been set to 'windows_working_group' 00:00:34 <dag> jtanner: :-) 00:00:36 <nitzmahone> Hello- welcome to the inaugural meeting of the Windows Working Group! 00:00:42 <jtanner> #chair dag 00:00:53 <nitzmahone> #chair jtanner dag 00:00:53 <zodbot> Current chairs: dag jtanner nitzmahone 00:01:07 <jtanner> hah, get it ... chair, ballmer 00:01:19 <jtanner> ok, i'll stop 00:01:19 <nitzmahone> jtanner lives in the 90s 00:01:55 <jhawkesworth> hello 00:01:55 <jtanner> nitzmahone: so true 00:01:58 <nitzmahone> Agenda is at: https://github.com/ansible/community/issues/153 00:02:06 <nitzmahone> #chair jhawkesworth 00:02:06 <zodbot> Current chairs: dag jhawkesworth jtanner nitzmahone 00:02:11 <nitzmahone> Howdy Jon! 00:02:18 <jhawkesworth> hey 00:02:27 <jborean93> Hey all 00:02:37 <nitzmahone> Jordan! 00:02:44 <nitzmahone> #chair jborean93 00:02:44 <zodbot> Current chairs: dag jborean93 jhawkesworth jtanner nitzmahone 00:03:08 <jborean93> forgive me if I'm slow, this is my first meeting on IRC so might not know the rules 00:03:10 <dag> nitzmahone: I has some stuff listed here: https://github.com/ansible/community/issues/152 and we also moved some stuff here: https://public.etherpad-mozilla.org/p/Ansible_Windows_Community_Plan 00:03:31 * dag sounds like borat 00:03:36 <nitzmahone> lol 00:04:21 <nitzmahone> Basically, there's a bot (zodbot) that records the meeting, and we can do various callouts to it with # commands to record action items and stuff 00:04:43 <nitzmahone> #topic housekeeping 00:04:53 <jtanner> https://wiki.debian.org/MeetBot for reference 00:05:13 <jborean93> thanks for the info 00:05:25 <nitzmahone> So, we're currently set to do this every other week on Monday and Friday, with alternating times on both ends of my day to hopefully better accommodate our worldly schedules. :) 00:05:41 <nitzmahone> We'll see how that goes, and may adjust down the line 00:05:59 <jhawkesworth> cool 00:06:14 <nitzmahone> #topic 2.3 status 00:06:46 <nitzmahone> 2.3 is currently in feature + module freeze, so theoretically only bugfixes will be merged from this point on 00:07:14 <nitzmahone> I've got 2 release-blocking bugs right now in the new exec-wrapper stuff that I'm working on 00:07:25 <nitzmahone> I *think* I know how to fix both 00:07:42 <jhawkesworth> wishing you luck nitzmahone 00:07:54 <nitzmahone> Beyond that, there's a bit of cleanup on the exec wrapper stuff that I'm planning to do (eg, KEEP_REMOTE_FILES is nonfunctional right now) 00:08:09 <dag> anything related to privilege escalation ? I have some issues there 00:08:25 <jborean93> What are your plans with KEEP_REMOTE_FILES now that we are not copying files over in a normal sense? 00:08:36 <nitzmahone> dag: yes- "become" is busted under NTLM/Kerb 00:08:41 <nitzmahone> "Access is denied" 00:08:54 <nitzmahone> Works under Basic/CredSSP, haven't tested cert but assume it'll work 00:09:31 <nitzmahone> jborean93: I had a crusty prototype that persisted the wrapper and the payload 00:10:10 * dag is looking for a good way to find out why a task is "hanging" (never ends, no clue what's happening) 00:10:12 <nitzmahone> But I want to filter the payload a bit so we'll never persist a become password (since normally that only appears on stdin) 00:10:43 <dag> (same command works fine from powershell) 00:10:44 <nitzmahone> dag: hrm, haven't run into that yet 00:10:55 <nitzmahone> Lots of things can cause that though 00:10:57 <dag> nitzmahone: it's always those pesky installers :-( 00:11:03 <jborean93> dag: I've seen that before but for the life of my can't remember what it was 00:11:05 <nitzmahone> ugh 00:11:25 * dag needs a way to strace an existing process 00:11:28 <jborean93> dag: I've seen some specific cmdlets cause it to happen but it was a year ago that I came across it 00:11:37 <nitzmahone> If it involves an installer, by default I assume it's a WinRM/job issue over an Ansible issue ;) 00:11:54 <jhawkesworth> dag: logging stuff locally is the only way I know 00:12:10 <jborean93> #help with installers win_msi vs win_product 00:12:51 <jhawkesworth> anything else on 2.3 before we move on? 00:12:58 * dag also has a case where win_msi works better than win_package BTW, but we're deprecating win_msi :-/ 00:13:12 <dag> let's check my list :) 00:13:15 <nitzmahone> I haven't pulled the trigger on deprecation yet 00:13:54 <jhawkesworth> I'm less bothered about deprecating win_msi now as it seems to be raising less questions at the moment 00:13:54 <nitzmahone> There are some enhancements I want to do to win_package to get feature parity/ease-of-use parity with win_msi before I kick the leg out from the stool it's sitting on. ;) 00:13:56 <jborean93> dag: I've had the opposite with win_msi where it didn't detect a failure, I don't like win_product due to the product_id requirement. Had conflicting info regarding not setting it and using blank values 00:14:10 * dag likes to improve the existing modules and testing before v2.3 00:14:12 <nitzmahone> jborean93: that's a big one- 00:14:34 <dag> jborean93: we have a fix where you can do product_id=auto 00:14:41 <jhawkesworth> trond hindenes has done some work on making win_package more flexable 00:14:47 <nitzmahone> Except for the "idempotent URL-hosted case" there's no reason win_package should require a product code for an msi 00:14:50 <dag> jborean93: only works if product_id can be determined from package 00:14:59 <jhawkesworth> needs testing. 00:15:14 <jhawkesworth> and there's loads of broken packages out there without proper product_ids 00:15:18 <dag> jhawkesworth: indeed, needs to test that too 00:15:19 <nitzmahone> I'm hoping trond will be in Friday's euro-friendly-timezone meeting 00:15:59 <dag> Is someone keeping track of this ? :-) -> test trond's win_package improvement 00:16:29 <nitzmahone> I won't be able to get to that for awhile, so if one of you guys wants to play with it... :) 00:16:33 <dag> action for jhawkesworth/dag 00:16:47 <nitzmahone> We won't be shipping that for 2.3 anyway, so there's not really a rush for anyone who's not running devel ;) 00:17:02 <dag> oh :-( 00:17:08 <nitzmahone> #action jon/dag to test trond's win_package updates 00:17:32 <nitzmahone> Module freeze for 2.3 was March 15 00:17:47 <nitzmahone> Sorry, March 1 00:17:50 <dag> right, but I thought that was for new modules 00:18:01 <nitzmahone> and feature changes 00:18:07 <jtanner> bugfix only 00:18:11 <dag> damn 00:18:12 <nitzmahone> If there's no new UI, it's iffy 00:18:28 <jtanner> 2.4 will be here before you know it 00:18:29 <nitzmahone> If it was guaranteed ready to go and had tests today, I'd be OK 00:18:48 <dag> jtanner: $CUSTOMER project finishes before v2.4 00:19:06 <nitzmahone> But RC1 could be cut as soon as Wednesday, so nervous to hack up a module that much this late in the game 00:19:14 <dag> sure 00:19:19 <nitzmahone> dag: /library is your friend 00:19:20 <dag> I understand 00:19:32 <dag> it has been my friend for a long time :) 00:20:00 <jtanner> make sure they know how to test devel before you leave 00:20:03 <jtanner> problem solved 00:20:07 <nitzmahone> If we can keep some momentum on this and coordinate efforts for future releases, should make life better all around 00:20:48 <dag> nitzmahone: will the newline-changes to win_template/template not make v2.3 either then ? 00:21:12 <nitzmahone> They still could- that's arguably a bugfix 00:21:17 <dag> jtanner: I was told that they do not plan to update anything after I leave :-D 00:21:26 <jtanner> dag: wrong way to ansible 00:21:36 <dag> jtanner: no use in convincing me ! 00:21:47 <jtanner> i know, i'm half joking 00:22:06 <jtanner> i've worked for that co before 00:22:12 <dag> ah :-) 00:22:51 <dag> nitzmahone: can my open PR's (related to idempotence) be accepted before v2.3 ? 00:23:01 <dag> I consider that bugfixes... :-P 00:23:23 <nitzmahone> The newline sequence PR touches so much stuff that I'm not sure we'll get enough thumbs-up to get it in 00:23:43 <nitzmahone> I guess it's mostly tests... I dunno 00:24:21 <jhawkesworth> Damn netsplit. Catching up on my cellphone 00:24:26 <dag> most files it touches are testing 00:25:36 <nitzmahone> dag: which other PRs are you talking about re: idempotence? 00:25:47 <dag> nitzmahone: I meant check-mode, not idempotency 00:25:49 <nitzmahone> win_service / win_choco? 00:25:53 <dag> https://github.com/ansible/ansible/pulls?q=is%3Aopen+is%3Apr+author%3Adagwieers+label%3Awindows 00:26:09 <jhawkesworth> Templating is sort of fundamental. But the integration tests give a bit of confidence. 00:26:26 <dag> so #22501, #22311, #21371 and #21351 00:27:12 <dag> I think you dropped these because they did more than what was stated, so I dropped cosmetics 00:27:14 <nitzmahone> Yeah, I'll take the check mode stuff for sure, I'll have to talk with a couple others about the template stuff 00:27:41 <nitzmahone> (not a matter of not accepting, just "fudging" freeze) 00:27:45 <dag> ok 00:27:48 <nitzmahone> vs 2.4 00:28:09 <nitzmahone> #action nitzmahone to check w/ core team on templating newline fixes for 2.3 00:28:26 <nitzmahone> Hrm, wonder if we lost the bot in the split? 00:29:14 <jhawkesworth> my connection is back 00:29:19 <jtanner> erm, maybe? 00:30:07 <nitzmahone> #halp 00:30:22 <nitzmahone> looks like bot is still floating in ether. :( 00:30:44 <nitzmahone> Oh well, anyway... 00:31:31 <nitzmahone> So I'll test/merge what I can before RC1 00:31:36 <jhawkesworth> Is there anything windows community can take off your plate for 2.3 nitmahone? 00:32:16 <dag> more idempotency/check-mode tests of windows modules ! 00:32:24 <nitzmahone> If anybody wants to either triage new Windows-related issues/bugfixes, that'd be cool 00:32:41 <nitzmahone> I think beyond what we already have, that's going to have to be 2.4 00:33:57 <nitzmahone> Jordan's taken a whack at NTLM message encryption- I haven't had time to play with it, but I've got a passel of pywinrm stuff to do right after 2.3 is put to bed 00:34:32 <jhawkesworth> agreed. I'm trying to help out where I can but if anyone else has capacity for triage this is a good url to start: https://github.com/ansible/ansible/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3Awindows%20-label%3Aneeds_info%20-label%3Afeature_idea%20 00:34:45 <nitzmahone> We've got @($large_paying_customers) clamoring for kerberos message encryption, so that'll probably be my #1 post 2.3 00:35:43 <jhawkesworth> nice. Sounds involved though, hope you'll have time for some other stuff too during 2.4 00:36:09 <nitzmahone> Oh yeah, I don't actually think it'll be too bad once I get into it- just hoping it doesn't require changes to pykerberos 00:36:20 <jborean93> Kerberos encryption is a lot harder than NTLM, there is an example on the Ruby WinRM library 00:36:22 <nitzmahone> The main bits I need are there 00:36:26 <jborean93> Kerberos isn't my strong suite unfortunately 00:36:55 <nitzmahone> Toughest part of all these things is coordinating changes/availability to upstream projects :) 00:37:15 <nitzmahone> That's why life is a lot nicer when they're limited to things I have commit rights to... 00:37:19 <jborean93> oh it is a massive pain, getting the CBT stuff into NTLM required a few handoffs 00:37:33 <nitzmahone> Major kudos for that, though. :) 00:37:43 <jhawkesworth> hear, hear! 00:38:24 <nitzmahone> Any other specific PRs people want to talk about? 00:38:48 <jborean93> Maybe around the win_service side 00:39:08 <jborean93> dag wuestions whether we should have added the Force parameter around stopping and restarting a service when it wasn't there before 00:39:23 <jborean93> My thoughts was if we want to stop it should stop but not sure if that is the wanted behaviour 00:39:27 <nitzmahone> Hrm, as opposed to state: restarted? 00:39:31 <jborean93> It has been merged in but it might be best to merge it out 00:40:00 <dag> force could be optional 00:40:02 <jborean93> More around the -Force parameter https://ss64.com/ps/stop-service.html 00:40:09 <dag> I think that was my proposal 00:40:13 <jborean93> yep 00:40:23 <nitzmahone> Ah, gotcha 00:40:24 <jborean93> currently it isn't optional and it just forces it 00:41:22 <nitzmahone> Yeah, that's a tough call 00:41:27 <jhawkesworth> I don't think I stop/start any services with dependenices ATM. 00:41:58 <nitzmahone> I think since we don't return the list of deps, we probably shouldn't default to force 00:42:26 <nitzmahone> Not sure I picked up on that particular change 00:42:35 <jborean93> win_service does return the lsit of dependencies now after that PR 00:42:47 <nitzmahone> oh yeah 00:43:07 * nitzmahone is stale on current state of win_service code 00:43:49 <jhawkesworth> feels like it ought to be optional. plenty of other modules with a 'force' param that defaults to false (lowest risk of change against current released behaviour) 00:43:55 <nitzmahone> So the only other potential issue with "default force" then IMO would be if you stopped a service that depended on HTTP 00:44:00 * dag wanted win_service to be the reference module for Windows module development, but it has grown in complexity since :-/ 00:44:40 <nitzmahone> as you'd lose WinRM 00:44:49 <jborean93> I feel bad because I made those changes :( 00:45:03 <nitzmahone> Oops, wait, NM 00:45:18 <nitzmahone> I think it needed to be done, though 00:45:20 <dag> jborean93: was this before or after v2.2 ? 00:45:26 <jborean93> after 2.2 00:45:37 <jborean93> it was that PR we merged in before the freeze happened 00:45:51 <nitzmahone> win_service still isn't too bad, and I really disliked the alternative of making each service attribute its own module 00:46:08 <jborean93> I can raise another PR that changes the default behaviour to be False for -Force but it might take a day or 2 as it will break the tests 00:46:13 <nitzmahone> We've had a request to add service ACLs to that (or add service capability to win_acl) 00:46:24 <jborean93> You can do that? 00:46:37 <jhawkesworth> new one on me too! 00:46:45 <nitzmahone> Yeah, there's no UI for it, but service objects have control ACLs 00:46:55 <nitzmahone> I've had to mess with them before 00:47:11 <jborean93> interesting, sounds like I need to do some googling tonight 00:47:14 <nitzmahone> But beyond that, I don't see the surface area of win_service growing significantly going forward 00:47:23 <jhawkesworth> lot easier to lock the machine in a cupboard :-) 00:47:29 <nitzmahone> :P 00:47:48 <nitzmahone> So I was ok with the changes 00:48:07 <dag> jborean93: IMO if it wasn't released you haven't broken anything (but I know bcoca disagrees) 00:48:19 <dag> (releases as in an official release) 00:48:55 <nitzmahone> jborean93: if you want to try and tweak the Force behavior to default false, I think I'd be OK with that for 2.3 as well 00:49:49 <nitzmahone> But it'd be new UI... 00:49:54 <jborean93> dag: haha sounds like a good way of thinking 00:50:03 <nitzmahone> I *really* don't want to wait for 2.4 to invert that default 00:50:22 <jborean93> I'll try and get the changes/tests happening sometime tonight or tomorrow night 00:50:35 <nitzmahone> It only really matters on "stop" though... 00:50:37 <bcoca> dag: i dont disagree 00:50:38 <dag> jborean93: devel is devel, things may break or get reverted, I don't think we need to be compatible with our own breakage 00:50:38 <jhawkesworth> new optional parameter is least evil in this case 00:50:57 <jborean93> #action jborean93 update win_service with optional force parameter 00:51:16 <dag> bcoca: you wanted me to add documentation clarification for stuff only introduced and reverted in less than a week IIRC :-) 00:51:17 <nitzmahone> #action nitzmahone will face wrath of core team for breaking freeze rules 00:51:35 <bcoca> dag: it was unclear 00:51:40 <jhawkesworth> we'll stand behind you in a line 00:51:49 <jborean93> This is a bugfix for a breaking change :) 00:51:52 <jhawkesworth> admittedly from several timezones away 00:51:53 <bcoca> not saying devel is sacrosanct, 2 diff things 00:52:05 <jborean93> I broke win_service default actions and it needs ot be fixed 00:52:35 <nitzmahone> But we still need a way to stop w/ deps, so agreed that new optional arg is best solution 00:53:10 <nitzmahone> It's arguably a corner-case, regardless, but if you happen to need it, you're screwed without it 00:53:29 <jborean93> cool that was it for me around PR/2.3 changes 00:53:46 * bcoca leaves out joke about already being scrwed by using windows in production 00:53:59 <nitzmahone> jborean93: OK, just ping me on the PR when you get it and I'll hustle it in 00:54:09 <nitzmahone> Anyone else? Going once... 00:54:19 <jhawkesworth> no 2.3 from me 00:54:26 <jtanner> where do new windows devs start? 00:54:28 <jborean93> bcoa: My Mum says Windows is cool, she wouldn't lie 00:54:46 <jtanner> lets say nitzmahone gets hit by a bus and a sev1 ticket comes in ... what doc do i start with? 00:54:55 <dag> jborean93: You can steal stuff from here: https://github.com/ansible/ansible/pull/20539 00:55:06 <dag> jborean93: parameter documentation and stuff :) 00:55:18 <nitzmahone> jtanner: docs are left as an exercise for the reader 00:55:25 <jtanner> =( 00:55:27 <dag> although there was an issue with the provided test example 00:55:30 <jhawkesworth> jtanner: truth be told far too much of what I know about powershell comes from flaky stackoverflow answers 00:55:36 <nitzmahone> But srsly, that'll be a personal focus for 2.4- 00:55:41 <jtanner> i can google primitives 00:56:01 <jtanner> python -> winrm -> powershell workflows are what i presume i can't google 00:56:17 <nitzmahone> I've had this major doc rewrite that's been half-done and invalidated a couple times already just for *user* docs; dev-docs are almost completely missing 00:56:32 <nitzmahone> jtanner: not important for module dev so much 00:56:36 <dag> jhawkesworth: You'll love this one: https://www.simple-talk.com/sysadmin/powershell/a-plethora-of-powershell-pitfalls/ 00:56:46 <jborean93> dags: idea of having a standard reference module is good 00:56:55 <nitzmahone> jtanner: but if you want to hack on the actual Ansible exec wrapper, yeah, a lot of interactions to understand 00:57:05 <jhawkesworth> thanks dag 00:57:22 <jborean93> That was a major issue I had when starting was just finding out the best way of doing something 00:57:33 <jtanner> nitzmahone: i think it's inevitable someone else on our team other than you is going to have to do it 00:57:34 <nitzmahone> Yeah, there are plenty of turds in the pool ;) 00:57:38 <jtanner> your plate is piled too high 00:57:57 <dag> nitzmahone: can we get a fix in for the XMLCLI output, to me that's probably the most annoying thing in Ansible+Windows 00:57:59 <nitzmahone> jtanner: we're working on that problem too ;) 00:58:14 <nitzmahone> dag: yeah, that's on my 2.3-ish bugfix list 00:58:15 <jtanner> nitzmaHA ? 00:58:30 <dag> CLIXML 00:58:35 <dag> nitzmahone: perfect ! 00:58:54 <nitzmahone> It may or may not make it for 2.3.0 depending on how many RCs we do, but it can go before 2.3 00:58:58 <nitzmahone> s/2.3/2.4 00:59:02 <dag> nitzmahone: if you can give hints how to tackle it, I don't mind looking at it 00:59:29 <dag> nitzmahone: idem for other stuff 00:59:37 <nitzmahone> I wrote a crusty function to filter the CLIXML in winrm.py- mainly just needs to be moved out into a shared location 01:00:18 <jhawkesworth> ooh, when there's example of shared location, can you point it out. 01:00:30 <nitzmahone> Also depends on if we always filter from python- if not, I'd have to implement a PS/.NET version of it too 01:01:15 <jhawkesworth> there's various PRs knocking around for looking up SIDs which would be best off in shared a place 01:01:21 <nitzmahone> The layered exec wrapper stuff sorta argues for a .NET version 01:01:23 * dag assumed CLIXML handling would be part of pywinrm 01:01:49 <nitzmahone> Except that we get it back from internal layers that are using runspaces too 01:02:00 <dag> if it's powershell, that rules me out :-/ 01:02:29 <jborean93> nitzmahone: I need to pick your brain at some point around making changes to pywinrm and not breaking things 01:02:42 <nitzmahone> I just merged a PR today that should make it a lot quieter w/ async/become- there was some cruft from Add-Type that made it hella noisy 01:02:48 <jborean93> The PSRP stuff currently is working in my branch but needs some work around handling the changes made 01:03:57 <nitzmahone> Cool. 01:04:18 <nitzmahone> I'd probably try to implement as a subclass of Protocol or something 01:05:06 <nitzmahone> Well, we're technically over time- any other burning stuff to discuss before we call it a day? 01:05:43 <jhawkesworth> no, just really glad this is happening! 01:05:52 <nitzmahone> Me too- long overdue (and totally my fault) 01:06:34 <nitzmahone> OK, closing up in 5 . 4 . 3... 01:06:41 <jhawkesworth> I plan to test my (upgraded) playbooks against 2.3 starting next week 01:06:50 <nitzmahone> Noice 01:06:52 <jhawkesworth> cheers everyone 01:07:08 <nitzmahone> Thanks everyone! We'll see you around the mines... 01:07:10 <nitzmahone> #endmeeting