20:00:26 #startmeeting Ansible Windows Working Group 20:00:26 Meeting started Tue Nov 24 20:00:26 2020 UTC. 20:00:26 This meeting is logged and archived in a public location. 20:00:26 The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:26 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:26 The meeting name has been set to 'ansible_windows_working_group' 20:00:34 slacin 20:00:38 howdy 20:00:38 slackin' 20:00:44 #chair jborean93 20:00:44 Current chairs: jborean93 nitzmahone 20:01:21 I went through some of the outstanding PRs in the agenda yesterday and merged them in 20:01:35 noice 20:02:38 #agenda https://github.com/ansible/community/issues/517 20:04:00 * nitzmahone wonders if anyone else is around, or if we should table those til there's more of a quorum 20:04:16 probably should wait if there's going to be anyone else 20:09:08 welp, shall we punt to next week? 20:09:54 sounds good to me 20:09:56 get some time back 20:10:15 hi 20:10:23 sorry lost trackof time 20:10:45 :( 20:11:03 thanks for merging those Jordan 20:12:04 hey 20:12:10 briantist: anything else you want to talk about this week, or should we just punt to next week? 20:12:13 if y'all are still around really wanted to ask about that psrepository cloning module, I'd love to work on it over the holiday weekend if it seems like a good addition 20:12:13 no worries, thanks for working on them 20:13:08 based on the snippet you shared it seems a bit complex to me 20:13:40 which parts do you think could be simplified? 20:14:20 I'm not if it can be simplified :) 20:14:38 😬 20:14:53 I can't say I understand the difference between `repos_when_missing` and `repos_when_updating` 20:15:11 sure! the difference between those is whether the repos file initially exists or not 20:15:39 the idea is that you can use that to initially set a module without updating it after the fact, or you can update it 20:16:15 in the case of the example, PSGallery is usually put in a repo automatically on first access, and want to replicate that, but don't necessarily want it to be updated after the first time 20:16:59 maybe I should step back: the way this works is not to clobber the whole repos file, it can operate only on the repos you specify, so that it doesn't prevent individuals from registering andf managing other repos 20:17:20 wouldn't it just be easier to ensure that the repo is there or not regardless of whether the actual repo file exists or not 20:17:31 say I want repo x, y, z to be copied to users a, b, c 20:17:41 it shouldn't matter whether the initial config is defined 20:18:14 yeah that's possible too. It doesn't change implementation much. 20:19:15 I just don't know why you would want to add a repo only when the repository.xml file doesn't exist but not when it does exist 20:20:04 to set it initially, but to not touch it if someone has an established file. Mostly it's for the PSGallery case, felt wrong to overwrite it, but it's probably fine 20:20:34 well PSGallery is always the same is it not? 20:21:06 in theory! 😝 Anyway, if it makes it more palatable to be included in the collection, I'd be fine cutting down to a single option like you described 20:21:46 Personally I think it shoudl just be, something that defines the repos to copy then another which defines the users to copy to 20:22:07 That makes more sense to me as well- I'd imagine that'd simplify the impl and tests a bit 20:23:03 do you mean removing the include/exclude params? 20:23:31 totally fine with collapsing the repos down to a single param 20:23:51 I think the include/exclude are fairly straightforward though? 20:24:09 Something like this https://www.irccloud.com/pastebin/OUUN5tt0/ 20:24:51 potentially both accept a wildcard allowing someone to do `name: '*'` and/or `user: '*'` or even partial matching 20:25:16 a hard list without wildcards is difficult though becuase most of the value is in copying to users you don't necessarily know exist, so the typical use case is `*`, with some excludes for things that generally you don't want. 20:25:21 ok yeah 20:26:07 the system ones are also hard because the way the profiles are "discovered" is file filesystem, but system profiles live in different places and need to be dsicovered via registry. So it makes for special cases if they are includes n users 20:26:19 I do like the wildcards for repos though 20:28:46 wouldn't be insurmountable, I could find the system profile paths and include them in the list of places to search, that could be fine for letting system users be specified in the same params maybe 🤔 20:29:16 if anything you would be converting the same to a SID which can be used to tell if they are one of the system account 20:29:44 they might be excluded from the wildcard and require an explicit opt in but I don't fully know the use case for setting repos under those accounts 20:30:45 at the moment none of the functionality needs ot mess with SIDs so hopefully can avoid that. The use case for the system accounts (especialy LocalSystem) is stuff running under those, like anything DSC. Definitely useful in my environment but may not be for everyone 20:34:04 but yeah I think Ic ould get the system accounts to be specified in the same place as other users, call it `users:`, would prefer to keep the `exclude_users:` option as well though. `repos:` (or `name:`) can become a single param, no difference between new or updated file 20:35:04 I'm not against having an exclude option if the normal ones take a wildcard 20:36:16 sgtm, might add an exclude for repos in that case too. It keeps the default and commonly used options simple but allows for a little more control where needed 20:36:58 sounds fair 20:38:36 anything else you wanted to discuss on that one? 20:38:41 alright thanks fellas, I'll put some work into getting a PR for that 20:38:48 nope all good, thank you 20:39:34 awesome 20:39:59 I'll let all of us get to our days/afternoons then 20:40:02 thanks for coming 20:40:32 thanks, sorry for being late, been solidly booked with meetings and ad-hoc stuff today 😅 20:40:36 take care! 20:40:38 #endmeeting