20:00:26 <jborean93> #startmeeting Ansible Windows Working Group
20:00:26 <zodbot> Meeting started Tue Jul 16 20:00:26 2019 UTC.
20:00:26 <zodbot> This meeting is logged and archived in a public location.
20:00:26 <zodbot> The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:26 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:34 <bcoca> so implementing timeout for windows tasks ...
20:00:37 <jhawkesworth> hey
20:00:41 <bcoca> ;-p
20:00:42 <jborean93> #chair nitzmahone jhawkesworth
20:00:42 <zodbot> Current chairs: jborean93 jhawkesworth nitzmahone
20:00:47 <jborean93> #chair bcoca
20:00:47 <zodbot> Current chairs: bcoca jborean93 jhawkesworth nitzmahone
20:00:50 <jhawkesworth> :-)
20:01:00 <jborean93> hola
20:01:05 <nitzmahone> yo
20:01:20 <Shachaf92> יקט
20:01:21 <Shachaf92> hey
20:01:33 <jborean93> #chair Shachaf92
20:01:33 <zodbot> Current chairs: Shachaf92 bcoca jborean93 jhawkesworth nitzmahone
20:01:33 <jborean93> hey
20:01:36 <jhawkesworth> yay big turnout today
20:02:27 * jhawkesworth wonders how far back on agenda we need to go
20:02:38 <Shachaf92> here: https://github.com/ansible/community/issues/420#issuecomment-507493257
20:03:07 <Shachaf92> if agowa338wss cococomment   is ffinished
20:03:17 <Shachaf92> damn keyboard
20:04:09 <jborean93> I believe so, most of those PRs are awaiting a rebase or review conversations
20:04:39 <jborean93> mine is really just a request for review, can't remember if I mentioned it last week but everyone here has already looked at it so let's move on from there
20:04:57 <jborean93> #topic https://github.com/ansible/community/issues/420#issuecomment-508959447 wait_for_connection credentials
20:05:47 <jborean93> This is a fun one, I wouldn't want a behaviour change but wouldn't be too against a specific flag
20:05:58 <jborean93> the biggest issue is how do we detect if there was a credential failure
20:06:00 <nitzmahone> That's a slippery slope- wait_for_connection is designed to be resilient to things like "the DC is unavailable right now", but that would be an auth failure
20:06:05 <jborean93> right now we don't have an exception for it
20:06:27 <Shachaf92> i  mamde a possible iilemeentation  but haventt testede yet
20:06:39 <jborean93> plus each connection plugin has a big mix of exception handling levels
20:07:38 <Shachaf92> shouldi pursue this? or leaave it  be?
20:07:43 <jhawkesworth> yeah I guess different connections will behave differently when presented with invalid credentials.
20:07:54 <nitzmahone> It'd be good to have specific errors for some of those kinds of things, but a lot of connections aren't able to distinguish those failures anyway
20:08:03 <Shachaf92> this issue seems to focus on  winrm connectctction
20:08:18 <bcoca> nitzmahone: ignore_unreachable would be way to 'ignore auth issues'
20:08:23 <jborean93> wait_for_connection is not generic
20:08:26 <nitzmahone> It absolutely shouldn't be the default behavior, and if you start getting into lots of flags...
20:08:29 <jborean93> bcoca: he doesn't want to ignore auth issues
20:08:38 <jborean93> he wants to ignore connection failures but still fail on auth issues
20:08:46 <jhawkesworth> yes, but `wait_for_connection` is (deliberately) useful against win and non windows hosts
20:08:58 <jborean93> honestly I have half a mind to close saying we aren't aiming to do this but feel free to open a PR that covers all the bases
20:09:06 <bcoca> that would cover both .. since we consider 'auth failures' connection issues
20:09:15 <jborean93> I know
20:09:28 <jborean93> he only wants it to cover unreachable failures which it doesn't right now
20:09:35 <jborean93> cover only*
20:09:36 <bcoca> https://github.com/ansible/proposals/issues/141
20:09:51 <bcoca> ^ an expansion on that idea might cover his want .. possibly/mebbe/infuture
20:10:20 <jborean93> ok, any objections to me closing that saying it required better error detection and support for not just WinRM and link to that proposal?
20:10:31 <bcoca> works4me
20:10:47 <Shachaf92> +1
20:10:52 <jhawkesworth> no objection from me
20:10:53 <nitzmahone> (and also can't be the default)
20:11:01 <bcoca> workaround: use ignore_unreachable and then failed_when: 'auth' in error (whatever teh auth error is)
20:11:05 <jborean93> nitzmahone: of course, I rely on this feature right now :)
20:11:06 <jhawkesworth> yes, cannot be default
20:11:14 <jborean93> cool moving on
20:11:15 <Shachaf92> שערקק
20:11:18 <Shachaf92> AGREE
20:11:32 <jborean93> #topic https://github.com/ansible/community/issues/420#issuecomment-508960375 win_pagefile
20:12:57 <jborean93> so what's the issue here, it sounds like a bug where it's not reporting a page file?
20:12:59 <jhawkesworth> sort of wishing pagefile info was in facts, which doesn't really help specific issue
20:13:13 <nitzmahone> ditto
20:13:14 <jborean93> yea, this came out at about the same time we did a few `state: query` modules
20:13:36 <Shachaf92> in the case of auto managed in teh system level there is no pagefile in the usuall classes the module uses
20:14:06 <Shachaf92> so youll have to put a specific fix for that case just to return the paths used
20:14:19 <Shachaf92> i wanted to bring it up here to see if this is desiarialbe
20:14:21 <jborean93> so it's a problem where it's not reporting the path to the auto managed pagefile?
20:14:28 <Shachaf92> yeah
20:14:31 <jborean93> ah ok
20:14:36 <Shachaf92> desirable*
20:14:49 <jborean93> well 1 option is to create a `win_pagefile_info/facts` module and deprecate the query option for this one
20:15:01 <jhawkesworth> I don't have a problem with a specific case but its not something I'd use so don't know what this would be useful for
20:15:17 <jborean93> that way we can build the return values properly with something like this in mind
20:15:21 <Shachaf92> me neither
20:15:26 <nitzmahone> I think that's the right longer-term direction, assuming someone needs to know the actual details beyond "it's system managed" (why?)
20:15:37 <jborean93> they want a BSOD?
20:15:55 <Shachaf92> we can ask in the Issue maybe what is the actual use case
20:15:59 <bcoca> they fixed that with the xbox .. they made it green
20:16:08 <jborean93> bcoca: more like red
20:16:23 * jborean93 had a few Red Rings of Death
20:16:25 <bcoca> mine is GSOD .. have not seen red one (yet)
20:17:00 <jhawkesworth> yeah lets ask why this is useful.
20:17:06 <Shachaf92> ill ask
20:17:23 <jborean93> ok we can ask for the reasoning but I would be reluctant to make `state: query` better and just bite the bullet and create a separate module for that like we do today
20:17:36 <bcoca> -10 to state: query|list|info
20:17:43 <bcoca> facts/info module
20:17:46 <bcoca> instead
20:17:54 <jborean93> #topic https://github.com/ansible/ansible/pull/58483 setup failure handling
20:18:22 <jborean93> I'm personally happy to do the easy route here and then retroactively add nitzmahone's failure mechanism if they try to use this once that feature is in
20:18:40 <jborean93> right now having the setup module fail on some use cases is not a good situation to be in
20:19:09 <nitzmahone> Which one is "the easy route"?
20:19:25 <jborean93> try catch and return $null
20:19:37 <jborean93> for one knowing the machine sid isn't really that useful
20:19:43 <nitzmahone> true
20:19:52 <bcoca> setup module on 'posix' should not fail on facts, it skips them and adds either N/a or msg about the fact being unavailable
20:19:55 <nitzmahone> Seems like setup should never fail
20:19:58 <bcoca> not sure how windows side works
20:20:19 <bcoca> N/A and msg about fact
20:20:28 <jborean93> bcoca: it's a mix, before it would just ignore them but a change in 2.8 made error handling consistent across the board, i.e. it would actually report powershell errors
20:20:45 <bcoca> can you just return them as warnings?
20:21:04 <bcoca> i.e 'could not read sid: <error here>'
20:21:10 <bcoca> but then continue?
20:21:17 <jborean93> we can but I liked nitzmahone's idea of flagging the value so if the user tried to use it then it will fail with the error
20:21:37 <bcoca> that is 100x better, but feature needs to exist first
20:21:40 <jborean93> but that requires his deprecation/flagging work which is ongoing
20:21:43 <jborean93> yep
20:21:43 <nitzmahone> We can refactor to do that generally once it's in, but I'm ok with this more-or-less as-is right now
20:21:45 <bcoca> jinx!
20:22:03 <jborean93> cool, I'll review the PR to try to get it in soon
20:22:06 <jhawkesworth> flagging things sounds great.
20:22:36 <jborean93> #topic https://github.com/ansible/ansible/pull/58790 win_pester
20:22:38 <jhawkesworth> I can't think of a case where I'd use machine sid anyway, so happy to tip the balance in favour of having setup work without retrieving it for now
20:22:39 <nitzmahone> That way you don't have to care about how much noise there is from setup failures unless you actually care about a given value that couldn't be fetched
20:22:47 <jborean93> yep
20:23:08 <jborean93> I think the win_pester one is just a request for review
20:24:01 <jborean93> will attempt to get to it at some point but my plate is quite full right now
20:24:23 <jhawkesworth> it has a test - but I'm not using pester so hard to comment
20:24:43 * jborean93 feels like Mr. Creosote sometimes
20:25:06 <jhawkesworth> just one more PR.  It is only 'waffer thin'
20:25:54 * jborean93 explodes
20:26:17 <jborean93> #topic https://github.com/ansible/community/issues/420#issuecomment-511918582 win_service credentials
20:26:27 <jborean93> I think I know what the problem is here and commented this morning
20:26:40 <jborean93> oh wait wrong one
20:26:44 <jborean93> this is win_dns_client
20:26:51 <Shachaf92> i think i delete the comment
20:26:59 <Shachaf92> i saw your responce
20:27:00 <Shachaf92> se
20:27:14 <jborean93> #topic https://github.com/ansible/community/issues/420#issuecomment-511918582 win_dns_client disconnected interfaces
20:27:42 <jborean93> Would need to verify the behaviour with server 2012+, but if they don't fail on these types of interfaces then 2008/R2 should act the same
20:28:00 <Shachaf92> ill look into it
20:28:08 <jborean93> cool
20:28:34 <jhawkesworth> weird, I can't see that issue
20:28:37 <Shachaf92> maybe give a final go over thie
20:28:39 <Shachaf92> https://github.com/ansible/community/issues/420#issuecomment-502393874
20:28:49 * jborean93 still can't wait for 2008 EOL
20:29:09 <Shachaf92> I deleted the comment after i saw jborean93 commented on the issue
20:29:24 <jborean93> yea I was confused as I swear I saw that on the agenda :)
20:29:37 <Shachaf92> you did, and then you didn't
20:29:46 <jborean93> magic man
20:29:48 <Shachaf92> a magician
20:31:03 <jhawkesworth> I think I looked through all those PRs
20:31:22 <Shachaf92> I think so too and most if not all are commentless
20:31:50 <jhawkesworth> well I closed https://github.com/ansible/ansible/pull/38356
20:32:00 <jborean93> Shachaf92: did you not fix https://github.com/ansible/ansible/pull/40535 in another PR?
20:32:40 <Shachaf92> yeah in setup.ps1
20:32:45 <Shachaf92> this is the damn config script
20:33:06 <Shachaf92> there are like 10 issues and some PRs about it
20:33:21 * jborean93 wants to flamethrower that one as well
20:33:31 <jborean93> ah ok
20:34:55 <Shachaf92> Im working on the side on making a report to start cut down on old issues / multiple problems in a single file
20:35:14 <jborean93> I feel like I'm just going to have to close the majority of these. They are quite old and most not relevant anymore, just need to wordsmith a nice way to saying that
20:35:52 <Shachaf92> well... you can always say "Seems this one has been inactive for a while, closing and feel free to reopen if relevant"
20:37:25 <jborean93> yep, nothing in there really stands out for more discussion
20:37:42 <jborean93> Unless you disagree or want to talk about anything else, I'll end the meeting shortly
20:37:46 <jborean93> #topic open floor
20:37:46 <jhawkesworth> I'll ping the contributor on https://github.com/ansible/ansible/pull/40535
20:38:17 <nitzmahone> I did a quick review on the pester one
20:39:02 <jborean93> thanks
20:39:52 <Shachaf92> i have a noob question about IRC and not ansible for a sec - how do you do the "* @jborean93 wants to flamethrower that one as well" messages?
20:40:08 <jborean93> type in `/me <message>`
20:40:32 <Shachaf92> thx
20:40:43 <jborean93> you're welcome
20:41:04 <jborean93> cool so sounds like we are all good
20:41:08 <jborean93> closing unless anything else
20:41:13 <jborean93> 5
20:41:13 <jborean93> 4
20:41:14 <jborean93> 3
20:41:18 <jhawkesworth> oh hang on
20:41:19 <jborean93> forever hold your peace
20:41:25 <jborean93> :)
20:41:42 <jhawkesworth> has anyone ever had to solve a problem where you need to wait till cpu is quiet before  running a task
20:42:04 <Shachaf92> ah? like not busy? or actually silent?
20:42:05 <jborean93> I've seen tasks get slower if something is pegging the CPU but never had to wait
20:42:06 <jhawkesworth> I have 2 playbooks hitting a single cpu box and they fight for runtime and one or other looses
20:42:31 <Shachaf92> if it's a single CPU it might make sense
20:42:49 <Shachaf92> a single cpu windows is a terrible idea
20:42:54 <jborean93> yea, I've had those cases where a single CPU machine was blocked by TiWorker doing it's stuff in the background
20:43:13 <jhawkesworth> yep.  test environment runs minimal footprint
20:43:33 <nitzmahone> Yeah, it's nearly impossible to do intelligently- having a task to wait for idle or something would likely not work too well, esp if you have more than one waiting, since they'll thundering-herd it
20:43:48 <jborean93> we are at the mercy of Windows thread and memory management here :(
20:44:09 <nitzmahone> There's actually a window message that you can subscribe to just for that, but it wouldn't really solve the problem here even if you could get at it from WinRM (which I'm not sure you can)
20:44:37 <nitzmahone> This is based on it IIRC: https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process.waitforinputidle?view=netframework-4.8
20:44:40 <jhawkesworth> fair enough.  Its going to be easier to get a second cpu or move one app onto a different box.
20:44:53 <nitzmahone> oh wait, that's a different one
20:44:54 <nitzmahone> but still
20:45:32 <jhawkesworth> good to know.
20:45:41 <jhawkesworth> thanks for chatting it through, that was it
20:45:49 <jhawkesworth> so  ... nothing else from me
20:46:32 <jborean93> cool
20:46:43 <jborean93> thanks everyone for joining today
20:46:47 <jborean93> #endmeeting