20:00:01 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:01 <zodbot> Meeting started Tue Jan 16 20:00:01 2018 UTC.  The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:01 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:22 <jborean93> yo
20:00:24 <nwsparks> hey
20:00:34 <nitzmahone> #chair jborean93 nwsparks
20:00:34 <zodbot> Current chairs: jborean93 nitzmahone nwsparks
20:02:54 <nwsparks> There were a few open issues I wanted to discuss...should we wait a few more mins for others?
20:03:03 <nitzmahone> Nah, let's roll
20:03:06 <nitzmahone> #info agenda https://github.com/ansible/community/issues/294
20:03:14 <nwsparks> #link https://github.com/ansible/ansible/issues/33858
20:03:48 <nwsparks> I put a comment on there with my thoughts...wanted to get more input before I did a PR to fix it
20:04:56 <nwsparks> basically in the original implementation of lineinfile he is translating something like c:\return\new to c:`return`new so that powershell will insert the line breaks
20:05:13 <nitzmahone> Yeah, trying to convert the escape sequences is definitely problematic
20:05:45 <nwsparks> My preference would be that the line is always treated literally...the intention of the module is to only manage a single line
20:06:11 <nwsparks> So allowing line breaks to be inserted goes against the purpose of the module
20:06:16 <nitzmahone> Since I try never to use `lineinfile`, I don't really have a strong opinion there.
20:06:34 <jborean93> I know people always try to use lineinfile for multiple lines and that ends up in a world of hurt
20:06:56 <jborean93> But in this case the `\r\n` conversion seems wrong
20:06:57 <nitzmahone> But yeah, I suppose that's why blockinfile exists, but we don't have the Windows equivalent
20:07:35 <nwsparks> The easier fix is actually option 2 which is just remove the validation lines and force people to use the Powershell way of creating line breaks `r`n
20:07:39 <nitzmahone> I wonder if/how a YAML multiline literal would translate as a way to handle that case
20:08:01 <nitzmahone> So long as you don't need to embed a ` in the file...
20:08:15 <nitzmahone> Multi-level nested escaping is always fun
20:09:02 * jborean93 hoping it isn't a core module
20:09:09 <jborean93> phew
20:09:13 <nitzmahone> lol
20:09:43 <nitzmahone> Like I said, I don't have a really strong opinion, but I will say:
20:10:10 <nitzmahone> * I think there needs to be a way to use escaped characters of some sort in the content
20:10:34 <nitzmahone> * I don't think we should try to interpret them ourselves as it's doing now
20:10:57 <jborean93> Well they should be using powershell regex to do that
20:10:58 <nitzmahone> Native Powershell escapes are *probably* the right way to do
20:11:02 <jborean93> We shouldn't be interpreting
20:11:06 <nitzmahone> yep
20:11:08 <nwsparks> Yah I agree
20:11:09 <bcoca> https://github.com/glehmann/lineinfile
20:11:26 <jborean93> Maybe a note in the docs that reference the powershell regex docs
20:11:32 <nitzmahone> Yay, go dep on Windows... :(
20:11:39 <nwsparks> If we just delete the block that I posted it should solve the problem...\r\n will always be literal. `r`n will cause a line break ``r``n will print `r`n
20:11:54 <nitzmahone> + ref for PS escape sequences in the content
20:12:15 <nitzmahone> Works for me
20:12:39 <it-praktyk> what do you think about use [System.Environment]::NewLine ?
20:13:21 <jborean93> This would have to be done on the YAML side so there is no way to encode that in without knowing that's not the string the user wanted
20:13:28 <dag> jborean93: correct, we need to use the escape characters of the platform
20:13:57 <jborean93> So keeping the regex to match as the input from the YAML would mean we just pass it into the relevant powershell regex operator
20:15:44 <nwsparks> Meaning we don't do any interpretation right? It's just passed as is
20:15:59 <jborean93> yep
20:16:01 <nwsparks> Ok
20:16:08 <jborean93> When people complain, say that's just powershell :)
20:16:12 <nwsparks> Lol
20:16:54 <nwsparks> Ok. I'll do a PR sometime soon with an update
20:16:57 <bcoca> reboot x3
20:18:27 <it-praktyk> I would like ask about a style of comments in module_utils/powershell/*.psm1. Can they be translated to PowerShell way?
20:18:52 <jborean93> it-praktyk what do you mean?
20:19:34 <it-praktyk> Now comments - e.g. in the file Ansible.ModuleUtils.Legacy.psm1 are #-based
20:19:37 <nitzmahone> They could be block comments (<# #>) but indent is a hassle
20:19:59 <it-praktyk> so we can't Get-Help <function_name>
20:20:53 <jborean93> I see no reason why they can't be, just a time and effort type of thing
20:21:08 <it-praktyk> and to find a purpose of the function we need open a source file
20:21:14 <nitzmahone> I'm not sure we want to do inline docs in there though; then we're shipping them to the tarhet
20:21:16 <nitzmahone> I'm not sure we want to do inline docs in there though; then we're shipping them to the target
20:21:30 <jborean93> True, didn't think of the size aspect
20:22:11 <nwsparks> Are the functions documented anywhere currently?
20:22:15 <nitzmahone> No
20:22:23 <it-praktyk> I can prepare some proposal and we will see what is a difference in size
20:23:02 <nitzmahone> We keep punting the new PS module API because I keep hoping we won't have to build/support large swaths of it if we move some stuff to the controller
20:23:03 <jborean93> Is there much use spending the effort? The cmdlets are used in the modules and aren't designed for adhoc purposed
20:23:43 <nitzmahone> The PS inline doc comment syntax is pretty verbose and IMO obnoxious to work around...
20:23:45 <it-praktyk> with PowerShell-style help we can generate (after preparing some wrap-up) web documentation for utils
20:24:00 <it-praktyk> but you don't need use all parameters
20:24:06 <it-praktyk> just .DESCRIPTION
20:24:39 <jborean93> If we do want to go that route, we would probably use the existing yaml design instead of trying to support the ps ones
20:24:40 <it-praktyk> I'm new in Ansible development, I'm preparing presentation for PSConf.eu 2018
20:24:49 <nwsparks> It would be kind of nice to easily see options and uses for the .psm1 files
20:25:47 <nwsparks> Instead of having to looks in the functions and figure out what params/values are supported
20:25:47 <jborean93> I do agree but what we would do for Powershell we should arguably do for the Python module utils
20:26:14 <it-praktyk> 'Use your PowerShell skills to extend Ansible workflows - create your own Ansible module for Windows platform' - it will be the subject of presentation
20:26:45 <nitzmahone> Yep- API docs on that stuff are all light-to-nonexistent, partly because we keep threatening to deprecate and/or make significant changes to large parts (for both Python and Windows)
20:28:13 <nwsparks> Is there any preferred place we could store the documentation other than in the module files? Would it be a waste of time for him to do a PR with an update for them?
20:28:26 <nitzmahone> It all grew very organically and mostly feels like a collection of utility functions more than an API right now; if we're going to the trouble to document, ideally we'd build something nicer to use first.
20:29:02 <jborean93> Yep, if anything it may be worth a proposal to the whole of Ansible instead of a Windows specific thing
20:29:02 <nitzmahone> I wouldn't be opposed to a single .DESCRIPTION on each function, but I probably wouldn't merge anything much more than that
20:29:09 <it-praktyk> I think that documented 'state before' can be good to start to refactoring
20:29:36 <nitzmahone> We're not looking at a refactor though- it'd be a whole separate thing (which is why the current stuff got moved to "Legacy")
20:29:56 <nwsparks> Gotcha. I always wondered why it was labelled legacy
20:30:03 <nitzmahone> The prototype stuff I did awhile back was all in C# with very thin PS wrappers around only a couple of things.
20:30:25 <nitzmahone> So the idea being that you could use the same API to build modules in C# or PS
20:30:45 <nwsparks> That would be neat
20:31:18 <nitzmahone> Every time I get close to going back to it though, somebody renews my hopes of control-side arg validation and it makes me pause.
20:31:36 <it-praktyk> a similar - non structured - comments are in different files too, I just provided an example, based on that legacy module
20:31:36 <nitzmahone> So much the better if the majority of that stuff was all handled in Python on the controller
20:33:48 <nitzmahone> We struggle with how much PS-ism vs Ansible-ism to adopt for these things. My *general* feeling is that we should make the APIs idiomatic for the target language/platform, but we also don't want to be writing multiple doc-gen processes for different platforms. We already have a YAML-based doc generator; to get consistent output, we'd have to build a PS version of it to extract those to get them into our webdocs (probably
20:33:48 <nitzmahone> wouldn't want to use the MS-provided ones since the output is totally different from ours)
20:35:20 <nitzmahone> We also don't want to get back into templating/modifying module_utils before sending them over (eg, we wouldn't want to strip the doc comments before sending) because then stacktraces are useless to correlate to line numbers.
20:35:59 <nitzmahone> We've toyed with the idea of caching on the targets, which makes the presence of inline comments/docs much less an issue, but it's not happening in 2.5 or 2.6.
20:36:23 <nwsparks> So best to just leave this one alone for now it sounds like?
20:36:31 <it-praktyk> ok, I understand, I can spend some time to change of documentation format - it help me also better learn what offer Ansible natively for PowerShell developers
20:37:37 <nitzmahone> I'd consider a one-liner .DESCRIPTION for the main public functions, but I don't really know how useful that would be without all the arg descriptions and stuff (which I'd probably veto at this point, sounds like jborean93 feels similarly)
20:38:27 <it-praktyk> OK, let's discuss your next topic
20:39:38 <nitzmahone> Couple things to review/merge on the agenda, but that's it.
20:39:42 <nitzmahone> #topic open floor
20:39:46 <nitzmahone> anything else?
20:39:59 <nwsparks> https://github.com/ansible/ansible/issues/25466 and https://github.com/ansible/ansible/issues/25077  should be able to close, not sure how long you want to wait on replies from reporter since theyre fairly old
20:40:53 <nwsparks> Other than that I don't have anything else
20:41:22 <nitzmahone> OK- wrapping up in 5..
20:41:27 <nitzmahone> 4..
20:41:32 <nitzmahone> 3..
20:41:36 <nitzmahone> 2..
20:41:40 <nitzmahone> 1..
20:41:44 <nitzmahone> Thanks all!
20:41:46 <nitzmahone> #endmeeting