20:00:01 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:01 <zodbot> Meeting started Tue Jan 22 20:00:01 2019 UTC.
20:00:01 <zodbot> This meeting is logged and archived in a public location.
20:00:01 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:01 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:11 <nitzmahone> #chair jborean93
20:00:11 <zodbot> Current chairs: jborean93 nitzmahone
20:00:11 <jborean93> hey
20:00:26 <it-praktyk> hey
20:00:48 <chopraaa> Hi
20:00:53 <nitzmahone> #info agenda at https://github.com/ansible/community/issues/420
20:00:56 * jborean93 need to reboot be right back
20:01:12 * nitzmahone snickers at the agenda issue number
20:01:22 * chopraaa laughs
20:01:49 <jhawkesworth_> hey
20:02:09 <nitzmahone> #chair jhawkesworth_ chopraaa it-praktyk
20:02:09 <zodbot> Current chairs: chopraaa it-praktyk jborean93 jhawkesworth_ nitzmahone
20:02:20 <nitzmahone> Howdy all!
20:02:26 <jhawkesworth_> heya
20:03:45 <nitzmahone> Jordan's rebooting
20:04:00 <nitzmahone> Looks like we have several things on the agenda for today
20:04:08 * jborean93 back
20:04:17 <nitzmahone> #topic https://github.com/ansible/community/issues/420#issuecomment-456051780
20:05:16 <nitzmahone> (win_disk_facts and dynamic disks)
20:06:14 <nitzmahone> I'm +1 for win_disk_facts including info about both of those, so long as it's readily available from the usual sources
20:06:33 <jborean93> yea I don't have any reasons for it to not include it
20:06:47 <jborean93> I haven't really played with it too much so it probably depends on the implementation
20:07:44 <nitzmahone> OK, I've commented as such on the issue and marked it as "waiting_on_contributor"
20:07:53 <nitzmahone> #topic https://github.com/ansible/ansible/pull/50781
20:08:30 <nitzmahone> (duplicating, potentially in an incomplete fashion, setup instructions for Windows module dev)
20:09:10 <chopraaa> Hm, i figured this was installed when we source the venv
20:09:13 <jborean93> sounds like we should link to our actual guide for setting up pywinrm
20:09:18 <nitzmahone> I guess I'd say you shouldn't be developing Windows modules if you don't have a working Windows environment for Ansible to talk to. I'd rather just link to the setup instructions as a prereq to that
20:09:19 <nitzmahone> yep
20:09:30 <it-praktyk> duplicating, where is it "the original" ? ;->
20:09:52 <jhawkesworth_> yeah pretty certain you will get pywinrm if you have ever installed ansible from pip for example
20:10:09 <jhawkesworth_> so yeah, +1 for pointing at existing setup instructions
20:10:12 <nitzmahone> There are lots of different ways to get the deps
20:11:11 <jborean93> heh looks like we only have pip https://docs.ansible.com/ansible/latest/user_guide/windows_winrm.html#what-is-winrm
20:11:20 <jborean93> probably should update that and link to that section
20:11:51 <nitzmahone> Yeah, my point was just that we shouldn't duplicate it at all (so if/when we update "how to get the deps" we only have to do it in one place)
20:12:06 <chopraaa> I just checked.
20:12:22 <nitzmahone> So it should just be an RST `L()` pointing at the right document
20:12:26 <jborean93> yep agreed, link to that section then potentially up that section in another PR
20:12:36 <chopraaa> Using source hacking/env-setup loads up pywirm on its own.
20:12:47 <chopraaa> Doesnt need to be explicitly installed
20:12:50 <jborean93> chopraaa: only if you have it already installed, it won't install it for you
20:12:53 <nitzmahone> Hrm, I don't think so
20:12:56 <nitzmahone> yeah
20:13:12 <jborean93> anyway you don't technically need pywinrm anyway now
20:13:19 <jborean93> you could use the psrp connection plugin
20:13:38 <nitzmahone> Yeah, those are all the kinds of things I want to avoid having to update in multiple places
20:13:46 <chopraaa> Yeah
20:14:03 <jborean93> it-praktyk: are you ok to change the PR to link to that section?
20:14:31 <it-praktyk> OK
20:14:59 <jborean93> cool, feel free to reach out if you need help with the link or to test out the doc generation after the changes
20:15:03 <jhawkesworth_> Thanks it-praktyk
20:15:10 <jborean93> pretty much do `MODULES=none make webdocs`
20:15:39 <nitzmahone> (I just commented on the issue with how to do the link)
20:15:49 <nitzmahone> s/issue/PR/
20:15:58 <jborean93> nitzmahone++
20:16:13 <nitzmahone> #topic https://github.com/ansible/ansible/issues/51063
20:16:50 <nitzmahone> (case sensitive choices)
20:17:14 <jborean93> currently Legacy.psm1 is not case sensitive while the new Ansible.Basic.cs is
20:17:32 <jborean93> Looks like basic.py is case sensitive, e.g. `state: ABSENT` doesn't work
20:17:33 <nitzmahone> I think we should probably err on the side of flexibility here and just do case-insensitive comparisions always for Windows modules (whether PS or C#)
20:17:59 <jborean93> I'm just wondering if we should add in a flag that changes this behaviour
20:18:03 <nitzmahone> Of course that could be problematic for native C# modules that aren't careful about case checking...
20:18:05 <jhawkesworth_> yeah case insensitivity is very windows
20:18:17 <jborean93> very powershell really :(
20:18:20 <chopraaa> Haha
20:18:21 <nitzmahone> (since C# string comparison is case-sensitive but PS is not)
20:18:54 <jhawkesworth_> -ceq is, isn't it?
20:19:15 <jhawkesworth_> but not a exactly a default.
20:19:20 <agowa338> Please consider windows allows case sensitivity since about 1 year now. So just assuming it's not will break on some usages. And even worse, it does on a per folder basis...
20:19:22 <jborean93> So I personally think we should default to being case sensitive to align to basic.py but give people the ability to change that
20:19:49 <jborean93> agowa338: this is more around module options, currently older style ones are not case sensitive
20:20:06 <jborean93> allowing you do to things like `state: ABSENT` when the choice is set as `absent`
20:20:33 <agowa338> Is it case sensitive on Linux? I think we should stick to the standard there. If it is, we should be, if it isn't we shouldn't be either.
20:20:50 <jborean93> no basic.py isn't
20:20:58 <jborean93> sorry it is, e.g. `state: ABSENT` will fail
20:21:02 <chopraaa> I think along with validateset, we can add an option for case_sensitive as well. Make all new ones case insensitive until deprecated?
20:21:08 <jborean93> the trouble will be for modules moving across to the newer format
20:21:43 <jhawkesworth_> I think a warning if it isn't lower case.
20:22:10 <chopraaa> agowa338: Please consider windows allows case sensitivity since about 1 year now.
20:22:10 <chopraaa> I think you meant the opposite.
20:22:30 <jhawkesworth_> its the sort of thing that I would tidy up when migrating playbooks to a newer version of ansible, but would be bummed about having to fix up just to get a (previously working) playbook to run through
20:22:31 <nitzmahone> Default case-insensitive makes the most sense for modules we have today, but maybe we need language-aware config for it or something (so eg if you were doing a c# native module it'd be case sensitive, but PS would not)
20:23:17 <chopraaa> This would break old playbooks though since we've migrated a lot of modules to ansible.basic already
20:23:29 <nitzmahone> Either that or deprecation + move to case-sensitive
20:23:31 <agowa338> chopraaa: jborean93 already clearified, I thought it was about all values for config options like also if a path is required and not only those with "hardcoded values" like absen/present/...
20:23:42 <nitzmahone> Defaulting to case-insensitive shouldn't break anything
20:23:52 <nitzmahone> case-*sensitive* default would break things
20:23:57 <jborean93> ok so change the default in Ansible.Basic to be case insensitive
20:24:16 <jborean93> #action jborean93 to make Ansible.Basic case insentive for choice comparison
20:24:30 <nitzmahone> Yeah, seems like the best thing for now- we can deprecate that behavior later or revisit if/when C# modules start happening
20:24:32 <jborean93> we can look at making that variable if we ever add support for C# modules
20:24:34 <dag> I would leave it at case-insensitive and migrate to case-sensitivity using the deprecation process
20:24:43 <dag> and not implement a flag to influence it
20:24:51 <nitzmahone> +1
20:24:53 * chopraaa agrees with dag
20:25:05 <agowa338> +1
20:25:13 <jborean93> ok, I can try and include that in the PR as well
20:25:44 <jhawkesworth_> I guess deprecating would be nice, so eventually we all wind up in the same place
20:25:46 <nitzmahone> #topic https://github.com/ansible/community/issues/420#issuecomment-456267514 (disabling resources)
20:25:47 <dag> having a flag means we have to support 2 cases and it will harm supporting those (i.e. people may have examplees which may not work for others)
20:26:03 <jhawkesworth_> which makes switching from non-windows to windows modules less fraught
20:26:25 <nitzmahone> Yeah, I think long-term just being case-sensitive is the right thing to do, just means we have to warn on case conversions
20:26:38 <jhawkesworth_> not that there are many that even look like simple replacements for each other
20:26:38 <jborean93> sounds good
20:27:05 <jborean93> thanks chopraaa for finding that scenario, would have never think about it
20:27:27 <jhawkesworth_> yeah, good catch
20:28:00 <jborean93> so the next one is around whether things like `state: disabled` should require the same options as `state: present`
20:28:16 <jborean93> I think it should but technically things like the actual source isn't required if it already exists
20:28:28 <nitzmahone> If we're going to create the resource if it's missing, seems like yes
20:28:31 <jborean93> And if that's the case I need to fix the docs as that is an example
20:28:45 <nitzmahone> disabled implies present IMO
20:28:56 <jborean93> ok so 2 for required
20:29:20 <nitzmahone> I could see it both ways
20:29:38 <agowa338> Think it should just throw an exception if it should be disabled, but is not present and no url has been specified imho...
20:29:52 <jborean93> I think the other way is a lot harder to document as it's based on the existing state of the resource. This way it's tied to the actual options chosen
20:29:57 <nitzmahone> Either that, or it's a runtime error if the args necessary for creation are missing and the resource isn't present
20:30:19 <nitzmahone> eg, disabling w3svc- should I have to specify everything about it even though we don't create it? Probably not
20:30:50 <nitzmahone> I usually end up doing the latter for flexibility
20:30:52 <jborean93> true
20:31:28 <nitzmahone> It just makes the module impl a little more complex, because you can't just rely on declarative argspec (or it needs a lot more required_with etc)
20:31:51 <jhawkesworth_> as long as there is a name or other unique(ish) identifier for a reasource then that ought to be enough to state=absent/ state=disabled it
20:32:27 <nitzmahone> Yeah, I think absent is pretty clear that you just need the "key", but some of the other ones are less clear
20:32:38 <jborean93> required_if won't work in this case but I get what you mean
20:32:53 <jborean93> ok, I'll update the module to include support for this
20:33:24 <jborean93> #action fix win_chocolatey_source to support state: disabled with key options
20:34:38 <nitzmahone> #topic https://github.com/ansible/community/issues/420#issuecomment-456277586
20:34:47 <nitzmahone> (appx/msix support in win_package)
20:35:28 <nitzmahone> I haven't played with these much, so I'm not sure about idempotence, etc with these...
20:35:51 <jborean93> the trouble I see with adding to win_package is that it already has unique behaviour that specific to appx/msix
20:36:01 <agowa338> The appx/msix support should be, but I don't have a windows box to test.
20:36:11 <jborean93> so the PR has install_all_users option which tells me this should be it's own module
20:36:21 <jborean93> but I see the benefit of having win_package being able to support it
20:36:34 * jhawkesworth_ hasn't ever knowingly installed an appx or msix
20:36:46 <jhawkesworth_> win_package is kinda huge already
20:36:59 <it-praktyk> bye
20:37:06 <agowa338> the install_all_users option could also be used with msi's, even though it most of the time vendor specific in it's implementation.
20:37:12 <nitzmahone> It'd be nice not to get all the download etc "for free"...
20:37:54 <agowa338> to be honest I would rather remove the "download url" etc functionality than splitting out the msix/appx support.
20:38:09 <jborean93> same but a lot of people rely on it
20:38:30 <jhawkesworth_> download part has been in forever, would break playbooks to remove it
20:38:47 <chopraaa> Isnt appx specific to windows store apps?
20:38:50 <nitzmahone> `ALLUSERS` support could be patched through for msi's
20:39:03 <nitzmahone> It's the impl used by them, but you can install out of band too
20:39:04 <jhawkesworth_> I can see the appeal of papering over all the various different windows installer technologies
20:39:09 <agowa338> jborean93: but that would not stop us from deprecating it... Downloading stuff should be possible through other modules, or not? And one could just check if the package exists than download it within a playbook...
20:39:17 <nitzmahone> We're not deprecating that
20:39:33 <nitzmahone> It's used very heavilty
20:39:42 <jborean93> it's harder also because it's a stableinterface
20:39:56 <jborean93> unless it was something egregious then we usually try and keep that the same
20:40:07 <jborean93> plus yes, it's unfortunately used everywhere
20:40:37 <agowa338> is it? How do you check usage of such options?
20:40:59 <chopraaa> lol
20:41:00 <nitzmahone> We can't, but probably 75%+ of the usages I've seen rely on the download
20:41:40 <nitzmahone> My kingdom for default-on module telemetry, but it'd never fly
20:41:50 <jborean93> we unfortunately Microsoft so no telemetry :)
20:42:12 <jhawkesworth_> I'd settle for opt in but I guess value is low
20:42:41 <nitzmahone> exactly- we had that in Tower for a long time and it was pretty much useless
20:43:01 <chopraaa> I think msix should be included with win_package
20:43:15 <dag> The irony here is that we deprecated win_msi ;-)
20:43:19 <jborean93> just for the ignorant, msix is the same as appx right?
20:43:22 <chopraaa> And appx should be separate or not done at all
20:43:31 <dag> in favor of a more generically named win_package :-)
20:43:37 <jhawkesworth_> yeah ... I don't know ... where are these things used?
20:43:39 <chopraaa> Msix was supposedly the replacement for older package installers
20:43:46 <nitzmahone> Anyway, I'm +0.5 for including it in the existing module- the current PR doesn't appear to vastly complicate the existing impl, and all_users support could be patched onto MSIs as well
20:43:46 <chopraaa> Appx is for windows store apps
20:43:48 * dag has a need for appx support
20:43:57 <dag> especially removing appx from clean Windows
20:44:25 <jborean93> ok seems like the consensus is to keep the PR as is in win_package
20:44:29 <chopraaa> Msix was talked about at ignite i think
20:44:35 <jborean93> any objections?
20:44:43 <agowa338> appx and msix do only differ by the file extension. The handling is similar.
20:44:52 <jhawkesworth_> windows seem to split installers as being either server-focused (dism) or end-user workstationy focused (appx)
20:44:55 <jborean93> chopraaa: I remember reading about it and thought, yay another packaging format
20:45:13 <jborean93> agowa338: cool, that's what it seemed like from the PR but wasn't sure
20:45:24 <chopraaa> Yeah supposedly theyre using manifests and making it easier to package
20:45:32 <jhawkesworth_> sounds like appx is of interest if you are managing windows 10.... windows server .. not so much
20:45:34 <chopraaa> Sort of like scoop does
20:45:35 <nitzmahone> It's not just store apps, it's the default install format for any UWP app
20:45:48 <jhawkesworth_> which you might want anywhere
20:45:54 <jborean93> side question, should the PR set the sideloading registry value?
20:46:01 <jborean93> https://github.com/ansible/ansible/pull/50864/files#diff-015c6ab28b2a53b29b2fa4d1d6c225ffR465
20:46:01 <nitzmahone> (which have a very high correlation with store apps, but not totally ==)
20:46:06 <agowa338> not only uwp. You can also ship desktop apps with it.
20:46:23 <nitzmahone> Right, but I think it's the only supported format for installing UWP
20:46:49 <agowa338> yes, that direction is true. The other not.
20:47:16 <jhawkesworth_> sounds like nicest ansible user experience is to have win_package do everything
20:47:29 * chopraaa laughs
20:47:39 <jhawkesworth_> not loving big modules though as they take so long to transfer
20:47:51 <chopraaa> win_msi rolls in its grave
20:48:23 <chopraaa> And we all know how fast winrm is
20:48:33 <agowa338> ssh
20:48:34 <jhawkesworth_> it won't bite me much as i don't use win_package much but I feel for anyone waiting for it to start
20:48:37 * jborean93 ssh isn't actually faster for execution
20:49:03 <nitzmahone> That's also one that the underlying execution takes long enough that the module xfer is mostly noise
20:49:03 <jborean93> ok, sounds like keep the PR as is, target towards win_package
20:49:05 <jhawkesworth_> sorry that sounded a lot like a moan.  Yeah lets have it
20:49:15 <chopraaa> +1
20:49:22 * dag thinks its better to keep them separate, but I'll go with the consensus
20:49:28 <dag> it's
20:49:30 <chopraaa> Also, tests please
20:49:31 <nitzmahone> cool, thanks for weighing in, everyone!
20:49:43 <jborean93> yes +1000 for tests
20:49:59 <nitzmahone> Yeah, ideally we'd have a locally-sourced or CI-sourced tiny appx/msix to test with
20:50:18 <jhawkesworth_> ^ would be cool
20:50:32 <nitzmahone> (eg, one that drops a single file that the test can check for to ensure the all users/local user installs are doing the right thing, etc)
20:51:12 <nitzmahone> ok moving on
20:51:15 <nitzmahone> #topic https://github.com/ansible/community/issues/420#issuecomment-456331641
20:51:22 <nitzmahone> new module review/decisions
20:51:47 * dag had issues installing and removing appx using Ansible and powershell scripts (years ago), but I think it was privilege-related, the WinRM support has been improved a lot, I should test it again
20:51:50 <nitzmahone> 2.8 freeze will likely be in March, so maybe we want to dedicate a working group meeting to going over them when we know we'll have a quorum?
20:52:09 <dag> nitzmahone: and invite the contributors to that meeting
20:52:31 <nitzmahone> that too, or at least ask them to comment on the modules with their willingness to maintain
20:52:34 <jborean93> that sounds like a good idea
20:53:13 <jhawkesworth_> not sure of the value of 'willingness to maintain'.  from personal experience I am willing but not necessarily able to get stuff fixed
20:53:33 <dag> For generic modules that's less of an issue, but the more niche stuff we really need to diversify
20:54:31 <dag> jhawkesworth_: I know it's hard, because it's not binding ;-) but at least we know the intention (hopefully)
20:54:33 <nitzmahone> Since we're all here- will everyone be available next week if we scheduled it then?
20:54:46 <jborean93> I'll be there
20:54:52 * chopraaa nods
20:55:00 <nitzmahone> o/
20:55:02 <dag> I may forget, so ping me :-D
20:55:03 <jhawkesworth_> yes, I will be around too
20:55:38 <nitzmahone> OK, sounds like we'll have a quorum, so let's plan on that. I'll drop notes on those and see if we can get some of the contributors there as well to talk about ownership
20:56:00 * jhawkesworth_ adds to diary
20:56:07 <nitzmahone> #action nitzmahone to notify pending new module owners for WG discussion next week
20:56:58 <nitzmahone> OK, I think that's everything from the agenda
20:57:04 <nitzmahone> #topic open floor (mind the gap)
20:57:44 <chopraaa> Did we miss win_git?
20:58:03 <nitzmahone> I didn't see anything on the agenda about it?
20:58:04 <jborean93> that's part of the module review next week?
20:58:06 <chopraaa> Oh, so that's pending for next week now
20:58:34 <jborean93> new module review seems to be next week
20:58:34 <jhawkesworth_> totally cheeky ask but any know of a good logrotate alternative for windows?  I've had enough of our in-house one
20:58:45 <agowa338> chopraa: one question about win_git, why does the normal git module not suffice?
20:59:00 <jborean93> agowa338: you can't run Python modules on Windows
20:59:11 <jborean93> so you would have to do `delegate_to: localhost` and win_copy it over
20:59:11 <nitzmahone> jhawkesworth_ WSL + logrotate?
20:59:13 * nitzmahone ducks
20:59:30 <jhawkesworth_> :-)
20:59:39 <chopraaa> :'D
20:59:47 <agowa338> so we need also a git module for Alpine and Archlinux?
21:00:08 <jborean93> but I would prefer to somehow add support for Python modules and not make a win_git, git is quite complex and hairy I don't really want that in Windows
21:00:28 <jborean93> Those distros run Python modules, it's just Windows that uses PowerShell
21:00:39 <nitzmahone> That would also be a very big meatball (though potentially enable some other interesting things down the line)
21:00:58 <jborean93> yea, right now the blocker is that basic.py uses some Python libraries that don't work on Windows
21:01:02 <agowa338> there is a pyton for windows, just saying.
21:01:07 <jborean93> but who knows what else it could be
21:01:10 <jhawkesworth_> yeah.  even picking a distro of python for windows would be hairy
21:01:11 <nitzmahone> Yeah, pretty much any Linux can install Python and "just work"- the whole module infra for Windows is completely different
21:02:01 <nitzmahone> Plus the whole wrapper for doing things like env and become; Ansible's not really set up to split module exec subsystems from platform exec subsystems today (though it probably needs to be)
21:02:41 <agowa338> +1
21:02:55 <chopraaa> I'm stoked about the c# modules.
21:03:24 <jhawkesworth_> if I had to do git stuff I'd delegate it to my ansible controllers and then send the results to windows box
21:04:11 <nitzmahone> I'm really inclined to leave win_git for galaxy with all the new stuff coming in 2.8+
21:04:17 <agowa338> I would say, we don't need a separate git module. A playbook writer could either just ship python or use expect. If git is installed...
21:04:37 <jhawkesworth_> we do some automated checkouts and tagging and stuff (in mercurial) but mercifully no need to do so on windows.
21:04:50 <jhawkesworth_> that said hg works just fine via powershell so I could
21:06:04 <nitzmahone> Well, we're over time- anything else pressing for this week?
21:06:12 <jborean93> nope I'm good
21:06:15 <chopraaa> Good to go
21:06:19 <jhawkesworth_> not seen what's coming in any detail but it feels to me like some of the niche usage modules would be best in a souped up galaxy
21:06:22 <jhawkesworth_> not from me
21:06:26 <jhawkesworth_> cheers
21:06:30 <chopraaa> Cheers
21:06:30 <nitzmahone> Thanks for all the discussion, everyone- hope to see all next week!
21:06:36 <nitzmahone> #endmeeting