20:00:03 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:04 <zodbot> Meeting started Tue Jun 25 20:00:03 2019 UTC.
20:00:04 <zodbot> This meeting is logged and archived in a public location.
20:00:04 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:04 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:13 <jhawkesworth> heya
20:00:14 <nitzmahone> bah, 3s late ;)
20:00:22 <Shachaf92> hey
20:00:25 <jborean93> hey
20:00:43 * jborean93 should hang your head in shame
20:00:43 <nitzmahone> #chair jborean93 Shachaf92 jhawkesworth
20:00:44 <zodbot> Current chairs: Shachaf92 jborean93 jhawkesworth nitzmahone
20:02:04 <nitzmahone> #topic https://github.com/ansible/community/issues/420#issuecomment-505595963
20:02:12 <nitzmahone> (which win_pagefile PR?)
20:02:54 <nitzmahone> At a glance Shachaf's looks like the winner to me
20:03:07 <nitzmahone> Basically making the existing behavior work the way it should have originally
20:03:12 <jhawkesworth> also adds override: 'match' option which I am not sure about( i think 'force: yes/no' ) would be more declarative.
20:03:13 <Shachaf92> I am a bit biased
20:03:32 <jhawkesworth> I think I favour the bugfix only one
20:03:40 <jhawkesworth> as it has a test
20:03:43 <nitzmahone> Also adds a test
20:03:45 <nitzmahone> jinx :)
20:03:51 <jhawkesworth> :-)
20:04:16 <jborean93> about to say that's a +1000 for me
20:04:36 <jhawkesworth> i guess adding reboot_required could happen in a separate PR
20:04:37 <nitzmahone> If someone wants to further tweak a force-like behavior later, fine, but anyone opposed to taking 57893?
20:05:04 <jborean93> no I'm good
20:05:11 <jhawkesworth> no objection from me
20:05:13 <nitzmahone> Yeah, the reboot_required would be nice. I'll comment on the other and say as much
20:05:25 <jhawkesworth> thanks
20:05:31 <nitzmahone> #topic open floor
20:06:12 <Shachaf92> I wondered if it would be useful to have a page (maybe under the progress stracker) with a tables of activity status of PRs and Issues
20:06:45 <jhawkesworth> there's something a bit like that (rather stale though) on the wiki.
20:06:50 <jborean93> the trouble is maintaining that, I would find it useful but unfortunately are prone to forgetting to update things as it goes along
20:07:02 <jhawkesworth> TBH I prefer to just search github for windows-related issues
20:07:04 <Shachaf92> i don't mind taking that
20:07:24 <Shachaf92> i already have something for the PRs on one of my agenda comments
20:07:51 <jborean93> if you are happy to do such a thing then by all means. Having it on the wiki would be the best place
20:08:01 <Shachaf92> K ill add it later
20:08:13 <jhawkesworth> yep, if you have the time to keep on top of it, would be great
20:08:40 <Shachaf92> a bit of OCD when it comes to lists so i`m happy
20:08:41 <Shachaf92> to
20:08:43 <jhawkesworth> I count 92 open windows issues which aren't feature requests at the moment
20:09:17 <Shachaf92> btw since all 3 of you can approve
20:09:19 <Shachaf92> PRs
20:09:35 <Shachaf92> mind reviewing the ones i have waiting?
20:09:48 <Shachaf92> (dog touched the keyboard)
20:10:48 <jhawkesworth> happy to take a look at PRs.  I struggle with stuff I have no knowledge of / cannot test.  PR numbers?
20:11:24 <jhawkesworth> FWIW I know I can merge PRs but usually limit myself to docs PRs these days.
20:11:58 <Shachaf92> 55862, 57281,57267, 57901, 57902, 58090
20:12:10 <Shachaf92> a review is always helpfull too :)
20:13:12 <jhawkesworth> Ok I will take a look at those and see what I can contribute
20:13:16 <jborean93> will attempt to have a look sometime this week
20:13:18 <Shachaf92> great thanks
20:13:31 <Shachaf92> I have nothing more to add
20:13:50 <jborean93> I don't see it on the agenda but there was a question around win_domain_user and password idempotence
20:13:55 * jborean93 tries to find PR
20:14:11 <Shachaf92> yeah he closed it i think, was an issue not a PR
20:14:14 <jhawkesworth> if I get time tonight I will take another look at the list here and see if any more of them can be closed off: https://github.com/ansible/community/issues/420#issuecomment-502393874
20:14:14 <jborean93> https://github.com/ansible/ansible/issues/58246
20:14:19 <Shachaf92> if not mistaken
20:14:20 <nitzmahone> ah yeah, saw that one go by, but was engrossed in something else
20:15:04 <jborean93> basically should we do something like win_user where we attempt to validate the pass by logging on the user before changing it, or just have something like the POSIX user where we don't touch the pass once created unless some flag is set
20:15:46 <nitzmahone> I'm thinking the latter
20:15:54 <nitzmahone> Or at least have it opt-in
20:16:02 <nitzmahone> Too dangerous to potentially lock someone out
20:16:27 <nitzmahone> I don't mind having the behavior, but I don't think it should be the default
20:16:46 <Shachaf92> yeah im against testing credentials more then you have to, and a mechanisem to test out user passwords (brute) with ansible seems a bit useless no?
20:17:03 <jborean93> yep, sounds like `update_password` shoudl have 3 states. `always`, `on_create`, `on_change` or something like that
20:17:36 <nitzmahone> Shachaf92: If you're meaning the potential for abuse, I'm less concerned about that, as there are *much* more efficient/effective ways to do that, but I'm with you on the first point
20:17:41 <Shachaf92> and then implemnt the test just for on_change?
20:17:58 <nitzmahone> That makes sense to me
20:18:14 <Shachaf92> what should be the default? always or on_create?
20:18:21 <jborean93> whatever it is right now
20:18:22 <nitzmahone> +1 for on_create
20:18:27 <nitzmahone> (IIRC the current default)
20:18:29 * nitzmahone checks
20:18:43 <jborean93> always is the default
20:18:50 <Shachaf92> i think it's always since you can update the password without creating users
20:18:56 <nitzmahone> oh, it does default to always
20:19:22 <jborean93> cool will update the issue with that
20:19:31 <Shachaf92> oh another issue that this one reminded me
20:19:34 * nitzmahone assumes the default was inherited from `user`
20:19:38 <Shachaf92> about the win_format
20:19:38 <jborean93> basically add a 3rd state that allows people to test the credential before checking if it needs to be changes
20:19:42 <nitzmahone> +1
20:19:51 <Shachaf92> +1
20:20:14 <jhawkesworth> sounds good to me
20:20:23 <Shachaf92> https://github.com/ansible/ansible/issues/58302
20:20:48 <nitzmahone> OK, win_pagefile fix merged and commented on the other impl
20:21:03 <nitzmahone> (GH squash-and-merge was busted for a bit there)
20:21:31 <jhawkesworth> Nice. thanks.
20:22:00 <nitzmahone> On 58302, I'm not opposed to implementing a 'force'ish option (so long as we call it something else)
20:22:15 * jborean93 yay win_format again
20:22:59 <Shachaf92> the problem he stated was that it dosn't return OK if same FS and size no?
20:23:03 <nitzmahone> Oh, NM, it's already there
20:23:23 <jborean93> I think so
20:23:51 <jborean93> It seems like he wants it to be idempotent if the file system is set to the input parameters which I thought is what it did currently
20:24:20 <jhawkesworth> Yeah I thought I tested that but must have missed a trick
20:24:52 <jhawkesworth> I think its reasonable.  if the imput parameters match the current state then it should just return 'ok'
20:25:19 <nitzmahone> agreed
20:25:32 <jborean93> then the "forcish" param is used to obliterate it regardless of idempotency
20:25:55 <Shachaf92> so simply return OK when the FS is the same?
20:26:04 <Shachaf92> and maybe allocation unit same too
20:26:04 <nitzmahone> (and not force)
20:26:19 <jborean93> I would return OK if all the input options are the same and not force
20:26:38 <jborean93> if any are different then a failure makes sense. The user can set `failed_when` if they wish to ignore it
20:26:41 <nitzmahone> I'm always nervous about the super-destructive operations
20:26:47 <Shachaf92> ill look into it during the week
20:27:27 <jhawkesworth> thanks.
20:27:29 <nitzmahone> Cool- thanks
20:27:34 <nitzmahone> Anything else for today then?
20:27:39 <jborean93> I'm all good
20:27:42 <Shachaf92> nope
20:27:46 * nitzmahone eyes kitchen hungrily
20:27:48 <jhawkesworth> all good here
20:27:57 <jhawkesworth> let nitzmahone eat his lunch
20:27:58 <nitzmahone> Aight then- til next week... Thanks all!
20:28:02 <Shachaf92> bed time
20:28:03 <jhawkesworth> cheers
20:28:07 <nitzmahone> #endmeeting