20:00:00 <jborean93> #startmeeting Ansible Windows Working Group
20:00:00 <zodbot> Meeting started Tue May 11 20:00:00 2021 UTC.
20:00:00 <zodbot> This meeting is logged and archived in a public location.
20:00:00 <zodbot> The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:00 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:05 <nitzmahone> o/
20:00:10 <jborean93> #chair nitzmahone
20:00:10 <zodbot> Current chairs: jborean93 nitzmahone
20:00:21 <jborean93> give it a few minutes to see if anyone else shows up
20:02:20 <jborean93> welp looks like it is just us
20:02:32 <jborean93> #topic https://github.com/ansible/community/issues/581#issuecomment-834941112
20:02:43 <jborean93> So there is an issue for how `win_package` operates in check mode
20:03:20 <nitzmahone> Maybe a warning?
20:03:25 <jborean93> currently it fails if the `path` specified isn't found but should this be the correct behaviour
20:03:53 <jborean93> it's a common problem with running things in check mode where it would work normally due to previous tasks running but in check mode the pre-requisites aren't there
20:04:19 <nitzmahone> That's always tough- check_mode is a tricky beast. It's always a fine balancing act between "do as much of the work as possible" without making it impossible to use.
20:04:31 <jborean93> yea
20:04:47 <briantist> heyyy
20:04:53 <jborean93> hey
20:05:10 <briantist> I looked over that `win_package` thing. imo it already does exactly what it should do
20:05:29 <nitzmahone> I actually proposed syntax for something like a "check_mode_task" alternative at one point, as well as check_mode specific args for stuff like command/shell, but it never really went anywhere
20:05:52 <jborean93> I tend to take a literal it works exactly like it would when running normally, including any checks and assumptions being done
20:05:52 <briantist> that would seem useful, yeah
20:05:55 <nitzmahone> Making real-world playbooks work in check mode can be *really* hard
20:06:07 <jborean93> but of course that has it's own problems
20:06:12 <nitzmahone> yep
20:06:42 <nitzmahone> Usually there are just a handful of problematic tasks, like where you need to chain the result of one task into the next (which would be a problem case for this one)
20:06:56 <briantist> as a real-world example, we often use `win_package` in our plays in combination with `win_get_url` and `file` (to create the download directory), where this issue comes in all 3
20:07:04 <jborean93> and I usually just say add `ignore_errors: '{{ ansible_check_mode }}'`
20:07:31 <nitzmahone> Yeah that's true- back in the day, that didn't always work ;)
20:07:40 <nitzmahone> But we template pretty much everything now
20:08:01 <briantist> I actually created a `win_downloader` role which always uses `check_mode: no` on the folder creation, and has an optional arg to use `check_mode: no` on the download part, that way, the really important task, `win_package` can give a better check mode result.
20:08:25 <nitzmahone> (well, and before we had the var- I used to do a hacky thing with a custom action to figure out if we were in check mode or not)
20:08:50 <nitzmahone> and yeah, having the explicit knob on the task is also really useful for that
20:09:03 <nitzmahone> (IIRC that didn't come until well into 2.x)
20:09:24 <jborean93> It was around 2.2/2.3 because I started using it then for stuff like this
20:09:40 <nitzmahone> Yeah, was pretty sure it wasn't in 2.0
20:10:24 <nitzmahone> But yeah, I could go either way- the current behavior is probably the safest, but if there were a lot of appetite to get rid of it, I'd say at least a warning in that case
20:10:31 <briantist> while I think the way those modules handle check mode is correct for them in isolation, in the context of a larger task, I want to be able to control certain aspects, and we'll never be able to do that close to perfectly at the individual module level I think
20:11:12 <nitzmahone> briantist: exactly- and the needs could differ depending if your check mode is looking for "correctness" vs "playbook dry run"
20:11:14 <briantist> like strictly speaking, in check mode the modules shouldn't make any changes, but I know in the cases I was referencing I don't care that a folder gets created or a (possibly kinda large) file is downloaded
20:11:35 <briantist> (but that decision is for me to make as an admin, for my specific situation)
20:11:46 <nitzmahone> ... and having a bunch of extra args to configure how a module behaves in check mode is probably not good either
20:11:53 <briantist> so  luckily, we have the tools to do so, via `check_mode` keyword, and `ansible_check_mode` variable, etc.
20:11:53 <jborean93> we could solve this particular scenario by only checking if `path` exists if a change needs to occur
20:12:17 <nitzmahone> Hmm, that might be a good compromise
20:12:34 <jborean93> the only trouble is if it isn't installed then it will still fail bringing us back to the beginning
20:12:37 <nitzmahone> (and just assume "changed: true" if it doesn't?)
20:13:01 <briantist> in many of the cases I'd use it (MSI files) the file is needed to determine if a change is needed anyway
20:13:09 <tadeboro> The rule we have for our playbooks is: check mode must go through without any errors only if the playbook has been executed beforehand. Check mode for us is "let see what would happend if we would run our playbook again". Anything else is too dependent on the current state of the system.
20:13:09 <briantist> (but maybe others use it with the other options)
20:13:40 <jborean93> in this case they have an explicit product_id set to avoid the msi requirement but others may not
20:13:44 <nitzmahone> briantist: well, not if you give it the product ID (IIRC), but yeah...
20:13:45 <briantist> interesting tadeboro , I take a more hard line approach, I want check mode to always work correctly, and always give the most accurate possible results, without failing
20:14:02 <nitzmahone> (thanks for proving my point you two ;) )
20:14:10 <jborean93> lol
20:14:13 <briantist> 😆
20:14:42 <nitzmahone> So I guess I'm also leaning toward "current behavior is good"
20:14:47 <tadeboro> So basically catch small deviations from the desired state. On larger deviations, we consider failing in check mode is OK.
20:15:01 <tadeboro> I am slow today: I read slow, type slow, all slow ;)
20:15:08 <jborean93> yea I'm on the fence but leaning towards keeping the behaviour
20:15:21 * nitzmahone got second shot yesterday, but is feeling suprisingly spry today
20:15:22 <jborean93> the alternative is too wishy washy and won't satisfy all scenarios bringing us back to here
20:15:29 <briantist> I'm pretty firmly for keeping current behavior
20:15:29 <nitzmahone> yep
20:15:36 <bcoca> should not really 'fail' in check mode
20:15:55 <bcoca> unless task will clearly fail
20:16:09 <jborean93> in this case the task would fail if the path doesn't exist trying to install it
20:16:25 <bcoca> ^ taht qualifies imho
20:16:53 <briantist> to say another way, I think modules need to act consistently in check mode (like it does currently), and making _plays_ work coherently in check mode is the responsibility of the author
20:17:11 <bcoca> +1
20:17:20 <jborean93> that's a good summary
20:17:25 <jborean93> I'll probably steal that :)
20:17:38 <tadeboro> I agree that trying to check the installation of something that is not on the disk is OK to fail in check mode because the non-check mode run would also fail under the same circumstances.
20:17:44 * bcoca just updated dev guide with that ...
20:17:48 <briantist> 👍
20:18:14 <jborean93> cool I'll update the issue and close it off thanks
20:18:17 <jborean93> #topic open floor
20:18:26 <nitzmahone> Yeah, the fact that it's running in check mode shouldn't introduce any *new* failures (which I think was where bcoca was coming from)
20:18:30 <jborean93> Nothing else on the agenda, is there anything we wanted to talk about
20:18:34 <nitzmahone> (and is not in play in this case)
20:18:46 <briantist> on the specific issue opened, I'm also happy to explain how I handle that in my own real-world case (I think their task copies a file rather than downloads it, but the idea is the same: copy the file in check mode anyway as long as that's ok for their use)
20:18:54 <jborean93> that would be great
20:19:14 <jborean93> I'm hoping to do a community.windows release sometime this week, just pending one last PR to be updated
20:20:32 <nitzmahone> #info Community Galaxy looking for feedbacl- probably seen in other channels, but JIC: https://www.reddit.com/r/ansible/comments/na4end/ansible_community_galaxy_next_steps_help_needed/
20:21:35 <jborean93> will be nice to see it unified
20:21:44 <nitzmahone> Basically "here's a summary of what you can do today- are we forgetting anything?" before we propose a few different options for "what might go away" when Community Galaxy gets migrated to the new codebase
20:22:10 <nitzmahone> Yeah- it'll be nice to have it pick up new features, bugfixes, and performance improvements
20:22:46 <tadeboro> And see the module documentation. That is what I miss the most right now when I switch from AH.
20:23:21 <nitzmahone> Yeah- having all plugin/role docs in there will be great
20:23:23 <jborean93> yes will be nice to drop the .py -> .rst script once Galaxy can show it
20:25:29 <jborean93> cool, is there anything else to talk about
20:25:35 <jborean93> if not will give us back 30 minutes
20:26:27 <nitzmahone> nothing here
20:26:50 <jborean93> going once
20:26:51 <briantist> nah I'm good
20:26:55 <jborean93> twice
20:27:00 <jborean93> three times
20:27:05 <jborean93> #endmeeting