20:00:28 <jborean93> #startmeeting Ansible Windows Working Group
20:00:28 <zodbot> Meeting started Tue May 18 20:00:28 2021 UTC.
20:00:28 <zodbot> This meeting is logged and archived in a public location.
20:00:28 <zodbot> The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:28 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:36 <nitzmahone> o/
20:01:24 <jborean93> yo
20:01:27 <jborean93> #chair nitzmahone
20:01:27 <zodbot> Current chairs: jborean93 nitzmahone
20:02:35 <jborean93> #topic open floor
20:03:42 <jborean93> nothing on the agenda
20:04:22 <jborean93> I don't really have much to talk about. Currently knee deep in a win_updates refactor which is proving to be quite messy
20:04:31 <jborean93> hopefully I can make it out the other end unscathed
20:04:40 <nitzmahone> at least we have good tests... oh wait... ;)
20:06:37 <jborean93> don't remind me :(
20:07:06 <jborean93> I'm currently banging my head with COM callbacks to get intermediate progress updates which has been "fun"
20:07:27 <nitzmahone> ah yes, COM interop callbacks are fun
20:08:58 <nitzmahone> I seem to recall some issues with that if the event callback has a strongly-typed interface, that you're kind of at the mercy of the caller to QI the right thing if you want to give it a dispatch-only interface
20:09:18 <jborean93> QI?
20:09:23 <nitzmahone> QueryInterface
20:10:06 <jborean93> the callback stuff itself is IUnknown, but the interface that you call to start the async call is at least IDispatch
20:10:33 <jborean93> I don't fully understand the distinction right now as they seem to be mostly the same in how it's defined
20:10:53 <nitzmahone> We should talk- this will be really simple to you once you understand a few things about COM
20:11:35 <nitzmahone> You likely won't be able to get the callbacks dispatched to you without a managed definition of the callback interface
20:11:54 <jborean93> it currently works, in that I can write to the console in the progress callback
20:11:55 <nitzmahone> (IUnk/IDisp are only precursors for getting the real one)
20:12:12 <jborean93> I'm just struggling to get the data back to the main thread but I have a few ideas/may not even need to in the end
20:13:31 <nitzmahone> If you can force the module to run on an STA thread you might be able to sidestep that problem, but PS definitely throws some monkeywrenches into that
20:14:51 <nitzmahone> Hopefully you can also avoid needing to implement a PInvoke wrapper for my favorite COM function: CoMarshalInterThreadIntefaceInStream
20:15:17 <jborean93> yea I essentially am creating a new runspace in the callback thread to run the scriptblock passed in because it can't use the TLS runspace which is expected
20:16:18 <jborean93> I was just getting crashes trying to add the data to a `BlockingCollection`
20:16:42 <jborean93> but I can't remember if I tried just adding a string representation at the time or if I tried to add the actual COM response
20:17:24 <nitzmahone> Yeah, using the native async collections might be more trouble than it's worth- I could see problems on either side there
20:17:44 <jborean93> ultimately I may not even need to get the data back to the main thread
20:17:59 <jborean93> just need a mutex to lock the output file and write to that and I think I will be good
20:18:52 <sgruber94> hi there :)
20:19:10 <jborean93> hey
20:19:52 <nitzmahone> So long as you're able to get at the object you want to dump results into from the callback's thread, you'd probably do better to just lock it yourself than trying to use a concurrent collection
20:20:43 <nitzmahone> Is the progress impl just for forensics, or are you actually letting the main thread poll for stuff in a true async way?
20:21:48 <jborean93> I'm using the action plugin to kick off the updates and then run a process to monitor the output path which contains progress updates
20:21:58 <jborean93> basically async for win_updates
20:23:20 <jborean93> it's a pity we don't have the update_json support in just yet but I still think I can get it working
20:24:25 <nitzmahone> Adding the raw COM callback object to a managed collection beyond the life of the callback could definitely cause problems
20:25:28 <jborean93> yea I think that's where I went wrong originally but I couldn't remember if I tried just converting it to json and adding that as a string
20:25:36 <jborean93> was going to be the first thing I try this morning
20:25:38 <nitzmahone> The default .NET interop marshaler *should* refcount it appropriately, but especially with those pseudo-reentrant things, it can get hairy fast
20:26:38 <nitzmahone> Is the primary reference to the COM update client being kept alive by the module code?
20:26:53 <jborean93> yep that is running and waiting for the completed callback to fire which works just fine
20:27:25 <jborean93> ignore the anon pipe stuff as that's just for me testing but here is the POC I have so far https://github.com/jborean93/ansible.windows/blob/win_updates-refactor/plugins/modules/win_updates.ps1#L1368-L1439
20:27:40 <nitzmahone> Ah, was just going to ask if you wanted another set of eyes on the COM bits in particular
20:28:12 <jborean93> I'm also going to rip out the error id to msg map and move it to the action plugin as it's currently about 500 lines long :(
20:28:36 <nitzmahone> bleh, yeah, nice to keep that all on the controller if you can
20:29:00 <nitzmahone> You should actually be able to get the system to do that for you
20:29:13 <jborean93> convert the HRESULT to an error message?
20:29:16 <nitzmahone> yeah
20:29:25 <jborean93> I tried in many ways but could never figure it out
20:29:39 <nitzmahone> Most dispatch libs have a built-in way to do that
20:29:52 <jborean93> I scanned all the .mui files in System32 and none of them contain the strings
20:30:04 <jborean93> I think we talked about this at the time as well
20:32:15 <jborean93> which is a massive pity as they are present in comments in the header files but that seems to be it
20:33:18 <nitzmahone> Yeah, I wasn't thinking about the IDispatch pattern for that- you should be able to QI for `ISupportErrorInfo`
20:33:35 <nitzmahone> (the primary update client object)
20:34:11 <jborean93> IIRc that's what COMException does in .NET
20:35:27 <nitzmahone> Maybe- it's been a long time since I've taken that apart
20:36:06 <jborean93> I just know there was a "common" way to get error messages from COM HRESULT codes but WUA didn't follow that pattern
20:36:17 <nitzmahone> You might have to set some metadata on the managed interface definition to get it to use that though
20:37:04 <jborean93> ah it was the `IErrorInfo` interface that had the common method
20:37:05 <nitzmahone> The FormatMessage way is "less common" (more for Win32 libs)- the ISupportErrorInfo/GetErrorInfo pattern should work on pretty much any IDispatch thing
20:38:19 <jborean93> https://github.com/dotnet/runtime/blob/01b7e73cd378145264a7cb7a09365b41ed42b240/src/coreclr/utilcode/comex.cpp
20:40:15 <jborean93> I can definitely test it explicitly though to double check as getting a localised error would be tops
20:40:27 <jborean93> very easy to generate a COMException with the WUA library
20:41:16 <jborean93> anyway let's leave that for offline, will close the meeting unless there's more to talk about
20:42:02 <sgruber94> heyi is there any next time for release?
20:42:18 <sgruber94> for thcommunity collection?
20:42:22 <jborean93> there was just one at the end of last week
20:42:26 <jborean93> 1.4.0 should be the latest
20:43:42 <sgruber94> ok. hm. did you have soonish time to review some PRs from me?
20:44:19 <jborean93> which ones in particular, I went through most of them at the start of the week that didn't have outstanding comments but maybe I missed some
20:46:39 <sgruber94> let me check i have some open in general #194 - #198
20:48:40 <jborean93> I'll have a look at them sometime next week once I finish with the win_updates stuff. Having a brief look there's only 2 that are green with CI so they will be the ones I will probably focus on first
20:48:59 <sgruber94> #193 is definitiley not ready, some PRs are "ready and waiting for your ReCheck" i requested  in some a review. and waiting  for you
20:50:45 <jborean93> ok will have a look when I can
20:50:55 <jborean93> might be a week or 2 sorry as I'm taking some time off soon
20:53:22 <jborean93> anything else we want to discuss?
20:54:34 <sgruber94> no discussion just some questions about PR "problems" i didnt catched well
20:55:46 <sgruber94> many thanks in advance that you are taking a look later :)
20:55:50 <jborean93> no worries
20:56:01 <jborean93> feel free to ask the questions here after the meeting if you wish
20:56:08 <jborean93> have a good one all
20:56:09 <jborean93> #endmeeting