20:00:25 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:25 <zodbot> Meeting started Tue Nov 27 20:00:25 2018 UTC.
20:00:25 <zodbot> This meeting is logged and archived in a public location.
20:00:25 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:25 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:32 <jhawkesworth_> hey
20:00:34 <nitzmahone> #chair jborean93
20:00:34 <zodbot> Current chairs: jborean93 nitzmahone
20:00:40 <nitzmahone> #chair jhawkesworth_
20:00:40 <zodbot> Current chairs: jborean93 jhawkesworth_ nitzmahone
20:00:44 <chopraaa> Whoa. Punctual
20:01:30 <jborean93> hey
20:02:03 <chopraaa> Hey folks
20:02:07 * nitzmahone consults agenda
20:02:23 <ksubileau> Hello
20:02:33 <chopraaa> Or as some people on the mailing list say, Hi Team
20:03:02 <nitzmahone> #topic https://github.com/ansible/community/issues/294#issuecomment-441460205
20:03:13 <nitzmahone> ksubileau, this one's yours
20:03:34 <ksubileau> Yep
20:03:48 <jborean93> My thoughts are with the comment I had on the PR, for nssm specific things use the executable, for other things I would err towards the cmdlets if possible
20:03:55 * jhawkesworth_ reading the comments still
20:04:33 <nitzmahone> I'm generally in agreement that the module shouldn't duplicate much of win_service; that's a testing burden we probably don't want
20:06:21 <nitzmahone> as far as the implementation details go (whether relying on PS primitives or nssm natively) I'm also mostly "whatever works"; if there's a good reason to wrap nssm for a given bit of functionality, do it, but if the same task is easier accomplished with PS, do what makes sense.
20:07:07 <nitzmahone> In general, wrapping arbitrary executables robustly is harder than using PS cmdlets, so I'd only use nssm for the parts where it's necessary
20:07:14 <jhawkesworth_> fwiw the way I use win_nssm is just as a wrapper for exes.  Because of problems with first versions of this, I just create a really basic configuration, then anything fancy like  500 character command lines needed to start some java apps, I do via win_regedit...
20:07:36 <jhawkesworth_> .. and for starting and stopping the services I've created with win_nssm, I use win_service
20:07:52 <ksubileau> So should we go to the solution I proposed at the end of my comment, despite the need of two task ?
20:07:53 <ksubileau> https://github.com/ansible/ansible/pull/45693#issuecomment-441459358
20:08:20 * jhawkesworth_ goes to read `win_nssm` module docs again
20:08:41 <nitzmahone> +1 to that; I think that's better than trying to duplicate a bunch of stuff from win_service
20:09:16 <nitzmahone> Use NSSM to create the basic "wrapper" service, then win_service to twiddle the bits the right way
20:09:22 <jborean93> I'm ok with that as well
20:10:15 <ksubileau> Ok, except the two tasks drawback, I think it's a good option
20:11:00 <jhawkesworth_> I don't really see having 2 tasks as a drawback, I'd much rather have 2 modules with a handful of parameters than 1 module with 20 args for readability
20:11:17 <nitzmahone> Plus we'd have to duplicate all the testing effort if everything was duplicated
20:11:35 * chopraaa agrees with jhawkesworth_
20:11:35 <nitzmahone> Small tight modules are the easiest to keep working as expected
20:11:36 <jborean93> and win_service tests aren't the fastest to begin with :(
20:12:08 <jhawkesworth_> I guess possibly a bit slower having 2 modules but this stuff is not really going to be a holding up
20:12:09 <nitzmahone> #agreed don't duplicate win_service functionality in win_nssm
20:12:17 <ksubileau> Ok so we're going to deprecate (or remove) display_name, description, start_mode, dependencies, user, password and state parameters, right ?
20:12:32 <jborean93> state should still be the same?
20:12:54 <jborean93> ahh there's a reloaded and so on
20:12:56 <nitzmahone> If those are direct args to win_nssm, I don't see a reason to remove them, but just don't duplicate all the advanced functionality
20:13:06 <ksubileau> Yes, reloaded, stopped...
20:13:15 <nitzmahone> hmm
20:13:28 <jborean93> definitely keep present/absent
20:13:30 <nitzmahone> Yeah, I guess it'd be good to remove the stuff that clearly overlaps
20:13:37 <nitzmahone> yes, state must stay
20:13:40 <ksubileau> and state:absent will be the same as win_service: state=absent
20:14:03 <nitzmahone> But the actual service control bits that are identical to win_service should probably get deprecated, so win_nssm is only for creating the wrapper
20:14:17 <jhawkesworth_> I'd keep display name and description as these are things that make sense to humans
20:14:24 <nitzmahone> Yeah, but state: absent on the resource should be OK to leave
20:14:35 <nitzmahone> requiring another module to get rid of it feels wrong
20:14:58 <nitzmahone> Yeah, the things that are already args to win_nssm should probably stay
20:15:10 <jhawkesworth_> yes, want to be able to get rid of the wrapper distinct from the service
20:16:09 <ksubileau> Ok, so we keep state: absent/present, display_name and description
20:16:13 <nitzmahone> ksubileau: you want to take a whack at what to deprecate of there (whether comment or in the PR, whatevs)?
20:16:28 <nitzmahone> sounds good to me
20:17:06 <nitzmahone> If it already has idempotent handling of those things, *probably* no sense in removing them
20:17:38 <nitzmahone> If we're going for "absolutely no overlap", win_nssm would be a create-only thing, which isn't what we want (I don't think)
20:17:58 <jhawkesworth_> yeah if you make it clear in the docs its for win_nssm is for configuring the wrapper side of things and that you should use win_service for service control (and win_regedit if you want to use advanced features that would be cool
20:18:05 <nitzmahone> +1
20:18:16 <jborean93> +1
20:18:26 <nitzmahone> ksubileau: does that get you going in the right direction?
20:18:57 <ksubileau> Yes sounds good :)
20:19:08 <nitzmahone> cool- thanks for running with that one!
20:19:18 <ksubileau> Last question
20:19:23 <nitzmahone> shoot
20:20:46 <ksubileau> Going back to the nssm executable question, should we use direct registry edit to change NSS parameters, or use the nssm executable ?
20:21:09 <nitzmahone> whatever's easiest; so long as you're not losing anything that the tool does
20:21:24 <nitzmahone> (by directly manipulating the registry, I mean)
20:21:26 <jborean93> I personally would use the executable. You don't know if they will ever change their implementation
20:21:33 <jborean93> or doing any special checks
20:21:41 <nitzmahone> Yeah, that's the trick
20:21:59 <ksubileau> Regedit seems easier to make idempotent, but may be broken by implementation changes
20:22:03 <jhawkesworth_> iirc the registry locations they use are picked to be compatible with some other service wrapper
20:22:07 <nitzmahone> The idempotence calculation may need to directly consult the registry anyway
20:22:32 <nitzmahone> (can't remember how easy nssm is to query/parse output from)
20:23:08 <ksubileau> I think the parsing is pretty well managed with the PR code
20:23:29 <ksubileau> But it still parsing...
20:23:46 <nitzmahone> Your call there, but definitely need to ensure anything *not* using the tool is reasonably safe to future changes the tool might make
20:25:26 <nitzmahone> Looks like it-praktyk isn't here, do we want to table https://github.com/ansible/community/issues/294#issuecomment-442096828 or discuss amongst ourselves?
20:26:12 <chopraaa> This is hilarious
20:26:18 <jhawkesworth_> sounds like the kind of thing best done with the contributor
20:26:33 <jborean93> I will apologise on the actual PR, I did step a bit too far but there were reasons why I did that in the end. In retrospec I should have talked about it a bit more but I wasn't having the best morning
20:26:45 <ksubileau> Ok, I think I'll use the executable except if it came too hard for some cases ;)
20:26:52 <ksubileau> Thank you
20:27:24 <jhawkesworth_> thanks for tackling it, hopefully suggestions above will make changes less arduous
20:27:26 <jborean93> But in general, if you think that I've handled something incorrectly or can do something better please let me know. We are all humans and can make mistakes from time to time
20:27:35 <nitzmahone> NO. NO MISTAKES. EVER.
20:27:36 <nitzmahone> ;)
20:27:37 <jborean93> yes thanks for looking into win_nssm and working through it
20:27:49 <jborean93> sorry I'm not bcoca :P
20:28:08 * nitzmahone awaits snark from target person
20:28:10 <chopraaa> I had a question about using powershell core modules
20:28:14 <jborean93> he's not here
20:28:23 <jborean93> fire away
20:28:24 <nitzmahone> chopraaa: go for it
20:28:43 <nitzmahone> (/me meant bcoca)
20:29:08 <nitzmahone> #topic open floor - PS core modules
20:29:12 <chopraaa> I think
20:29:18 <chopraaa> Woops
20:29:46 <chopraaa> How would i go about using core for both linux and windows hosts?
20:30:00 <chopraaa> Considering theres a lot of .net work being done recently
20:30:03 <jborean93> you can use core today for linux hosts, you just can't use our helpers
20:30:11 <jborean93> s/helpers/module utils/
20:30:20 <chopraaa> Yeah thats what i was leaning towards
20:30:45 <jborean93> For Windows it's a bit more complex. We don't have any tests running on it so nothing official but I'm trying to keep things in mind for the future
20:30:55 <chopraaa> And should windows modules be tested for core as well?
20:31:10 <nitzmahone> We're not ready to commit to that on CI
20:31:30 <chopraaa> By specifying a powershell executable somewhere in the config
20:31:39 <chopraaa> Ah, okay
20:31:41 <nitzmahone> So if you want to test things to make sure you haven't painted yourself into a corner, cool, but if it's not getting tested in CI, there's nothing keeping it from drifting back into "not working"
20:31:54 <jborean93> See https://github.com/ansible/ansible/issues/48881 for details on linux pwsh
20:32:20 <jborean93> yea, currently win_ping works on core but that's the extent to what I've tested
20:32:39 <nitzmahone> Windows will, at some point, make PS Core the "default Powershell", but it's probably still several releases out, given the compatibility thigns
20:32:40 <chopraaa> Neat
20:32:48 <jborean93> If you want to test it you can specify `ansible_psrp_configuration_name` with the psrp connection plugin and point it to PowerShell
20:33:26 <chopraaa> I'm still not up to speed with psrp and the new ansible module implementation.
20:33:27 <nitzmahone> The current compatibility packages are kind of a hack, they use implicit remoting to a PS5 session, which won't work for a lot of things.
20:33:42 <jborean93> and IIRC require the latest version of Windows
20:34:06 <chopraaa> Ill definitely look into testing this since i utilise powercli heavily.
20:34:08 <jhawkesworth_> that sounds very hacky
20:34:09 <nitzmahone> So we're still in "wait and see" mode on that or the most part
20:34:19 <nitzmahone> *for
20:34:28 * nitzmahone apparently can't type today
20:34:37 <nitzmahone> #topic open floor
20:34:46 <nitzmahone> Anything else for today?
20:34:51 <chopraaa> Theres a win_disk_management module still out in the wild
20:35:18 <jborean93> This is the original one right?
20:35:28 <chopraaa> Yeah thats the one
20:35:34 <jhawkesworth_> is that the one that someone was going to split up?
20:36:09 <chopraaa> It *is* getting split up i think.
20:36:12 <nitzmahone> Yeah, I think we wanted to go separate
20:36:16 <jhawkesworth_> cool.
20:36:16 <jborean93> well win_partition is in now, I think we still need something to manage disks themselves and format
20:36:24 <chopraaa> I pushed win_partition
20:36:55 <chopraaa> And wanted to ask for opinions on what to prioritise next. I personally needed partitions so i went for it first
20:37:20 <jhawkesworth_> I guess this stuff is perhaps a little harder to test than some other modules.  I don't deal with real disks much in $dayjob
20:37:45 <jborean93> I think format would be the next best option
20:37:48 <chopraaa> Volumes and formatting can be tested
20:37:57 <jhawkesworth_> true.
20:38:18 <chopraaa> Even then theres probably a lot about volumes that cant be tested i think
20:38:55 <chopraaa> Should there be separate modules for updating and initializing disks?
20:39:47 <jborean93> I probably don't know enough about the process but I would have thought having just 1 to manage the disks themselves is ok
20:40:14 <jhawkesworth_> personally a like a module to manage one kind of thing but need to see the args to see if its going to be nice to use
20:40:24 <nitzmahone> Yeah, win_partition is probably fine for very simple cases, but complex partition management is difficult to do in a tool like this
20:40:51 <nitzmahone> disk init seems more like an implicit thing if you're targeting one for an operation, init if necessary to get it done
20:41:16 <chopraaa> Yeah that sounds right
20:41:30 <ksubileau> If i can give two cents, i think that Ansible really needs modules to handle disks and partitions. It's a big lack currently, I had to improvise one for my profesionnal projects
20:42:47 <jhawkesworth_> sounds like you have some experience that might be useful to share.
20:42:59 * jhawkesworth_ is spoiled by virtualisation
20:44:55 <ksubileau> I've done something like a mix of the two PR
20:46:04 <nitzmahone> The tricky bit about disk management is making sure you don't accidentally nuke the wrong volume or something; disk numbers aren't always predictable, so you kinda have to work heuristically.
20:46:30 <nitzmahone> ... and that gets dangerous in a hurry when you're talking about tools that can zap volumes and/or data
20:47:18 <ksubileau> Because I needed to select a volume by its size, which is not currently possible with win_partition
20:47:23 <nitzmahone> Making a module that does what you want with the right input isn't terribly hard. It's just a matter of also providing the tools to *generate* the right input
20:47:27 <jhawkesworth_> desired state and heuristics are a heady mixture
20:47:35 <nitzmahone> indeed
20:47:55 <nitzmahone> "Make this thing that fuzzily matches criteria XYZ like this"
20:48:07 <nitzmahone> "oops, there went my DB storage"
20:48:18 * nitzmahone has never been there, nope
20:48:46 * jhawkesworth_ thinks you haven't lived until you've accidentally deleted a customer's database
20:49:00 <jhawkesworth_> it wasn't live at the time
20:49:06 <chopraaa> Well, now I'm skeptical D:
20:49:21 <nitzmahone> The selection stuff almost seems like it should be Jinja filters/tests or lookups against fact data vs something built into the module
20:50:06 * nitzmahone remembers sharing an office with a junior dev during a major marathon weekend deployment and hearing "uh, did I just delete production?"
20:50:45 <nitzmahone> "I don't know... did you?"
20:51:48 <jborean93> I haven't deleted a production database but I have brought an Oracle database to it's knees by running multiple queries in parallel
20:52:22 * nitzmahone left a giant transaction open overnight that held write locks on a central table in a production database
20:52:55 <jhawkesworth_> i have a playbook for checking for blocking locks.  comes in handy
20:53:07 * nitzmahone came into utter panic and customer service chaos the next morning, quietly walked to desk, typed, `COMMIT` and hit enter, all was well ;)
20:54:04 <nitzmahone> I've got another meeting to run to in a couple minutes- anything else pressing for today?
20:54:38 <jborean93> nitzmahone can fix things with a simple word, IT god
20:54:40 <jborean93> I've good
20:54:47 <jhawkesworth_> not really. I reckon coment on https://github.com/ansible/ansible/issues/48881 would make a nice blog post
20:55:18 <jhawkesworth_> oh is this 'state of the art' re windows and ssh at the moment: https://github.com/ansible/ansible/pull/47732 ?
20:55:36 <jhawkesworth_> looking for any kind of silver bullets to speed things up at the moment
20:55:37 <jborean93> I'm tapped out after writing about mapped drives...
20:55:46 <jborean93> gotta give me a month or 2 before Ican do another one :)
20:55:49 <nitzmahone> + feature request to PS team for a "skip terminal formatting" option
20:56:55 <nitzmahone> I'm figuring the next silver bullet will be connection persistence and module caching; did some experiments with psrp and it was noice
20:56:57 <jhawkesworth_> fair enough.  pre-requisite reading of windows internals book its hardly surprising you could do with a break.
20:57:56 <nitzmahone> Cool, thanks all. Until next week!
20:58:02 <nitzmahone> #endmeeting