Community: Windows Working Group agenda - Jul-Dec 2017

[dagwieers]

This agenda has been migrated to a new location: #294

---

The Windows Working Group is focused on improving Ansible's management of Windows hosts. The group meets every week on Tuesdays at 20:00 UTC (see ical)

More information related to the Windows Working Group is available at:
https://github.com/ansible/community/wiki/Windows

Feel free to add your questions to this ticket to be discussed during the upcoming meeting.

After being discussed, raised items are being updated, and after a month resolved items are being hidden from view (but remain accessible).

(Migrated from the previous agenda at #153)

[dagwieers]

New windows modules waiting for review/feedback:

• win_whoami: ~https://github.com/ansible/ansible/pull/33295~ new in v2.5
• win_disk_facts: https://github.com/ansible/ansible/pull/32935
• win_audit_policy_system: ~https://github.com/ansible/ansible/pull/31046~ new in v2.5
• win_audit_rule: ~https://github.com/ansible/ansible/pull/30473~ new in v2.5
• win_rabbitmq_plugin: ~https://github.com/ansible/ansible/pull/28017~ new in v2.4
• win_power_plan: ~https://github.com/ansible/ansible/pull/27966~ new in v2.4
• win_eventlog_entry: ~https://github.com/ansible/ansible/pull/27828~ new in v2.4
• win_eventlog: ~https://github.com/ansible/ansible/pull/27827~ new in v2.4
• win_disk_management: https://github.com/ansible/ansible/pull/27634
• win_firewall_rule: ~https://github.com/ansible/ansible/pull/27381~ (reimplemented)
• win_hotfix: ~https://github.com/ansible/ansible/pull/27260~ new in v2.4
• win_mapped_drive: ~https://github.com/ansible/ansible/pull/27020~ new in v2.4
• win_domain_group: ~https://github.com/ansible/ansible/pull/26682~ new in v2.4
• win_toast: ~https://github.com/ansible/ansible/pull/26675~ new in v2.4
• win_wait_for: ~https://github.com/ansible/ansible/pull/26556~ new in v2.4
• win_xml: https://github.com/ansible/ansible/pull/26404
• win_security_policy: ~https://github.com/ansible/ansible/pull/26332~ new in v2.4
• win_group_membership: ~https://github.com/ansible/ansible/pull/26307~ new in v2.4
• win_user_right: ~https://github.com/ansible/ansible/pull/26276~ new in v2.4
• win_wakeonlan: ~https://github.com/ansible/ansible/pull/26232~ new in v2.4
• win_certificate: https://github.com/ansible/ansible/pull/25837
• win_pagefile: ~https://github.com/ansible/ansible/pull/25605~ new in v2.4
• win_dsc: ~https://github.com/ansible/ansible/pull/24872~ new in v2.4
• win_domain_user: ~https://github.com/ansible/ansible/pull/24075~ new in v2.4
• win_psmodule: ~https://github.com/ansible/ansible/pull/23604~ new in v2.4
• win_route: ~https://github.com/ansible/ansible/pull/23405~ new in v2.4
• win_firewall: ~https://github.com/ansible/ansible/pull/23224~ new in v2.4
• win_defrag: ~https://github.com/ansible/ansible/pull/23140~ new in v2.4

Please review these tickets on a weekly basis (if there was new progress, otherwise add instructions to the owner how to continue).

Once merged, please add to CHANGELOG.md !

[dagwieers]

Effort to have integration tests for all Windows modules. Please review and merge:

• ~win_iis_webapppool -- @jborean93 -- https://github.com/ansible/ansible/pull/25869~
• win_iis_website -- @jborean93 -- https://github.com/ansible/ansible/pull/25902

[dagwieers]

~(@jborean93) Review and merge: ansible/ansible#23119~

Migrated from https://github.com/ansible/community/issues/153#issuecomment-286400853

[dagwieers]

(@dagwieers) Investigate and recover from "Connection refused" errors in WinRM. ansible/ansible#25532

Migrated from https://github.com/ansible/community/issues/153#issuecomment-307416504

[nitzmahone]

Discuss perf changes being made to Windows CI (windows/ci/smoketest, elimination of group1/2/3)

[dagwieers]

Can we get ansible/ansible#26533 merged ?

Update (nitzmahone): merged

[dagwieers]

~Can we get https://github.com/ansible/ansible/pull/26612 merged ?~

[dagwieers]

Can we get https://github.com/ansible/ansible/pull/26512 merged ?

Update (jhawkesworth): merged 20 July

[dagwieers]

Maybe it is time to think about what we still want to achieve before the v2.4 release. For example, it would be nice to finish integration tests for all modules that will ship in v2.4. Or have Windows coverage support. Or finish organizing the Windows/DSC documentation, etc.

What is achievable in the remaining time ?
And what can we communicate to the community if we need help ?

Update (jhawkesworth): Discussed. Summary: As much as we can.
Note that documentation can be tackled after core code freeze as code freeze does not apply to docs. Will be a module review before modules freeze. Coverage testing for likely to arrive after 2.4.

[jhawkesworth]

I'd like to discuss any ideas anyone has for making debugging powershell modules simpler and quicker to setup, following recent discussion on the #ansible-windows freenode channel.
Best way to tackle seems to be to set up sharing code between controller and windows host, load shared module code, run in ISE, load module code, run and debug in ISE. I will experiment and see if I can document something.
Update 2 (jhawkesworth): jborean93 made this documentation PR which has now been merged: https://github.com/ansible/ansible/pull/27308

[nitzmahone]

Realized I thought of this a couple weeks ago and didn't include it on the review, but do we want to rename win_group_member to win_group_membership to be consistent with some other things (eg win_domain_membership), since the resource we're editing is a membership, not a member...

Update (jborean93): agreed
Addressed in PR #27614

[andrewsaraceni]

@nitzmahone @jborean93 I can put in a PR for the rename if that's helpful (unless you're already taking care of it).

[nitzmahone]

@andrewsaraceni sure, go for it! If you do, please also rename in CHANGELOG... Thanks!

[andrewsaraceni]

Thanks @nitzmahone, just submitted PR https://github.com/ansible/ansible/pull/27614 for this - let me know if you see anything I missed.

Update: nitzmahone (merged)

[jborean93]

Would like a consensus for the variable we set when checking if --diff has been set. Currently I use $diff_mode but others are using $diff_support. This will make it easier to check if a parameter support diff if we use one variable.

See https://github.com/ansible/ansible/pull/26468#discussion_r131549379 for more details.

Edit: $diff_mode is the chosen option

[gundalow]

Ansible Contributor Summit 5 (Part of AnsibleFest 2017 San Francisco)

When: 2017-09-06:
Notes: https://public.etherpad-mozilla.org/p/ansible-summit-september-2017
Event will be in person + online (Video + IRC)

Agenda is open for topics for the next Contributors Summit

Please add (and vote +1) for any topics.

[gundalow]

NOTE: meetings are canceled for the week Aug 21st to 25th due to 'all hands' meeting for the core team. We will resume normal schedule after that.

[dagwieers]

I have some "old" new stuff to discuss:

• ~win_robocopy: Check-mode support, improved return code and docs -- https://github.com/ansible/ansible/pull/25410~
• ~win_get_url: Add use_proxy, headers and timeout -- https://github.com/ansible/ansible/pull/26612~
• ~win_shortcut: Fix for env variables/UNC paths -- https://github.com/ansible/ansible/pull/27089~
• ~win_reboot: post_reboot_delay parameter and async/check-mode fixes https://github.com/ansible/ansible/pull/28448~
• ~wait_for_connection: Remove transport_test for WinRM --
  https://github.com/ansible/ansible/pull/28450~
• pywinrm: Fix to retry on "Connection refused" (example) -- https://github.com/diyan/pywinrm/pull/174

[jhawkesworth]

~Could we spend some time seeing if there are any more modules that can make it in before the freeze?~ Update (jhawkesworth) done

Also re SID lookup utils, now that the .psm1 has been merged is anyone looking at getting the modules to use it? See https://github.com/ansible/ansible/pull/19219#issuecomment-325727518 Update (jhawkesworth) see update on comment below.

PR has been merged and issue closed

[jborean93]

@jhawkesworth I was going to have a look at using them in win_owner/acl/... but it will probably be a 2.5 thing.

Update (jhawkesworth) @andrewsaraceni has kindly volunteered to create a PR (at which point we can probably close https://github.com/ansible/ansible/pull/19219)

PR has been merged and issue closed

[gundalow]

NOTE: meetings are canceled for the week September 4th through 8th due to AnsibleFest San Francisco. We will resume normal schedule after that.

[dagwieers]

I implemented something I wanted to do before and was discussed once before, allow modules to update system facts (managed by setup.ps1). I believe this is what Ansible should be doing, if we know e.g. the system requires a reboot, there's no need to keep the existing system facts wrong.

Now, I don't know if my implementation for reboot_required vs ansible_reboot_pending is perfect, as I don't know if we want to consider both the same thing in this case, and what else there is to consider. I'll let the experts here decide that, but the general idea still holds (and we probably want to update other Windows modules to do the same thing).

• Windows: Introduce Set-Fact and set reboot_pending https://github.com/ansible/ansible/pull/29170

[nitzmahone]

discuss options for fixing https://github.com/ansible/ansible/issues/23019 (basically, breaking change or no?)

Edit: consensus was to make the breaking change and move to CreateProcess and document this in the porting guide

[jborean93]

Discuss https://github.com/ansible/ansible/pull/28995 and see if we want to split the module up into smaller pieces or keep it as one.

Edit: keep things as a single module

[jhawkesworth]

Discuss extra facts module(s) for windows.
I'm thinking of a win_installed_facts module which would have hotfixes (from https://github.com/ansible/ansible/pull/25917) and windows installer-installed product_ids.

Edit: consensus was to create a separate win_hotfix_facts and win_package_facts to return this information

[dagwieers]

~Tonight, at 19:00 UTC (one hour before the Windows Working Group meeting) we plan a second Windows Sprint. During this Sprint we will review a series of open issues and take actions to get them resolved. Everybody is welcome. If you have an open issue that requires some attention, feel free to bring it up.~

[jhawkesworth]

~I can't make 3 Oct meeting but would appreciate any thoughts anyone has about this WIP PR
https://github.com/ansible/ansible/pull/31231 Possibly may need me to explain what I was thinking though, so leave it if its too obscure to understand as it is.~

UPDATE: WWG discussed Oct 3, see comments on PR

Also, for info, but related to the above, I had some very rought thoughts about re-organising the windows docs which I put here: https://github.com/ansible/community/wiki/Windows--ideas-for-documentation-new-structure - I have parked this at the moment as I know jborean93 is working on windows docs,

[jhawkesworth]

~I'd like to discuss the implications of this https://stackoverflow.com/questions/5260125/whats-the-better-cleaner-way-to-ignore-output-in-powershell and in particular the final answer which appears to show that
sending things to the pipe is slow, rather than actually whether you use a [void] cast or a send output to Out-Null.
I just did a quick grep and found 60 occurrences of Out-Null in the modules in 20 modules.
If testing showed any actual speed advantage, would a PR to reduce the use of pipelining across modules be acceptable?~

discussed WWG. jhawkesworth to prototype on setup.ps1 using Measure-Command to see if there is actually any benefit.

[jborean93]

Looking at https://github.com/ansible/ansible/pull/31289, do we want to load the registry hive under a unique name and map it to a custom key in powershell like HKAN (or something like that). Or do we want to keep the current behaviour where it is always mapped to HKLM:\ANSIBLE and people just prepend that to their path.

The former makes it seem like we are loading a hive under a new key but in reality it is still being loaded under either HKLM or HKU so it really depends on whether we want to make it more like the native tools or take a step further.

Edit: decision was to use a fixed mount point but auto unload/reload if it is already mounted before running the module while throwing a warning

[jborean93]

The win_dsc PR https://github.com/ansible/ansible/pull/31556 fixes a few things with that module but also breaks compatibility with 2 things

* Dict type (CimInstance) in 2.4 need to be defined as a string, this PR changes it so it is a normal dict in YAML

Before:

- win_dsc:
    resource_name: xWebSite
    Ensure: Present
    Name: Ansible DSC Test
    State: Started
    PhysicalPath: C:\inetpub\wwwroot
    BindingInfo: |
      MSFT_xWebBindingInformation
      {
          Port = 8443
          Protocol = HTTPS
          HostName = *
      },
      MSFT_xWebBindingInformation
      {
          Port = 8888
          Protocol = HTTP
          HostName = *
      }

After:

- win_dsc:
    resource_name: xWebSite
    Ensure: Present
    Name: Ansible DSC Test
    State: Started
    PhysicalPath: C:\inetpub\wwwroot
    BindingInfo:
    - Protocol: https
      Port: 8443
      HostName: '*'
    - Protocol: http
      Port: 8888
      HostName: '*'

I can potentially add in backwards compatibility now that @trondhindenes has let me know how it was done before but strings can be quick finicky and was hoping to avoid it https://github.com/ansible/ansible/issues/31003#issuecomment-337077872

* The attributes and dsc_attributes have been removed as they were the same and there is even a third copy being set on the root result object. I didn't want to remove them all but was hoping to get rid of them before too many people start using the module

I was hoping to get a consensus from people around whether we should make these breaking changes or if we should try and keep compatibility. It is a preview module and was only added in 2.4 and I think these are changes for the best but will go with what the crowd thinks.

Edit: WWG said to make the breaking change and document it

[pablodav]

~Hello,~

~I was just curious about this: is it possible to support actual python modules in windows?~

~There are cases with modules like: git, docker_* and others like that that probably there is no difference or little difference between windows and linux, so could make sense to use same module on win/linux?~

EDIT: discussed at Oct 31 WWG IRC meeting- we're not opposed, but lots of groundwork probably required to get basic.py and others working reliably on Windows again. At this point we'd say "PRs welcome, but not supported". It's not a bad thing to think about as an alternative to building a parallel win_git module though...

[jhawkesworth]

I'd like to discuss whether its worth considering making a distinction between paths and command lines, following the discussion https://github.com/ansible/ansible/pull/32469
as @jborean93 observes originally the path type just enabled expansion of envrionment variables but then was later modified to validate paths. However in the case above the module parameter isn't simply a path to a file, but a command line (i.e. a path to an .exe plus optional command line args), so maybe over time the module parameter name aliased and then changed to 'command_line' (or something better).

Also perhaps having a 'expand' module parameter type might be a nice thing, which just expands any env vars. Suggestions for a better name welcome.

[dagwieers]

~@ar7z1 and I want to discuss how to manage firewall rules with overlapping profiles (https://github.com/ansible/ansible/issues/32478#issuecomment-342502306) in the next meeting.~

EDIT: discussed on Nov. 14 meeting, @ar7z1 to try adding basic filtering by profile; possibly a new allow_multiple arg for editing multiple matching rules. Also discussed rule merging, but that should probably be pursued separately later, as it's potentially a minefield...

[jhawkesworth]

~Just want to check everyone ok before I delete the following wiki pages which I think are now superceeded by the detailed windows guide documentation.~

~https://github.com/ansible/community/wiki/Windows%3A-documentation~
~https://github.com/ansible/community/wiki/Windows--ideas-for-documentation-new-structure~
~https://github.com/ansible/community/wiki/Windows-Paths---prescriptive-style~

~@jhawkesworth to delete pages after a quick scan for any content that didn't get migrated~
EDIT @jhawkesworth removed content, pointed at detailed guides.

[jborean93]

Quickly talk about the win_stat PR https://github.com/ansible/ansible/pull/33005 and the behaviour of some of the return values. Are the names of hlnk_targets and lnk_type fine, they are not used in stat so I had to set my own names here. Also currently stat does not set islnk: True when the file has other hard link references. I went the route of setting islnk: True in these cases as hlnk_targets and lnk_type are set accordingly in these cases but was hoping for a consensus before moving ahead.

EDIT: discussed Nov 21; islnk will only be true for symlinks, adding isjunction for junctions; hlnk_targets will always exist and be empty unless multiple links to the same content exist

[dagwieers]

I discovered an issue with the use of win_get_url where the default timeout parameter (at 10 seconds) behaves differently on Unix as on Windows. On Windows it appears to mean the complete download needs to finish within that timeframe, whereas on Unix this is related to the connection timeout, not the operation timeout.

A default operation timeout of 10 seconds is problematic, and breaks existing playbooks (on larger files).

EDIT: discussed Nov 21; appears to be related to delays before file download (possibly lab env quirk), @nitzmahone unable to replicate with short timeout and large file on devel

[pablodav]

~How do you setup windows environment for development?~

~Could be useful for new developers to have some reference in:
https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_general_windows.html#windows-integration-testing~

~Something like vagrant and molecule? https://github.com/metacloud/molecule/issues/607#issuecomment-347284381~

[dagwieers]

~@pablodav This is not a support forum, but the agenda of a meeting. You can discuss on mailinglist or IRC, open an issue related to new functionality (or documentation), or create a PR with suggested changes. Also look at: ansible/ansible#33515~

[quorten]

PR #26934 looks like it is ready for merging. The Windows Working Group should see if this should get merged or closed. From my testing, the change is required for proper IPv6 winrm support. It would be great if winrm IPv6 support could be functional for the Ansible 2.5 release.
(solved via https://github.com/ansible/ansible/pull/34072)

[jborean93]

I would like to talk about the win_disk_management PR, after reviewing it I think it should be split into 3 different modules as it touches 3 different components

* volumes/disks
* partitions of a disk
* format of a partition

I've put my thoughts in this comment https://github.com/ansible/ansible/pull/27634#pullrequestreview-83695637 and am interested in what the others think.

(EDIT: consensus is that it should be smaller modules, PR will be closed with that recommendation)

[jhawkesworth]

~~I suggest we postpone further meetings until 2018. ~~

[jborean93]

That's probably a sensible idea, both @nitzmahone and I will be away next week so should probably postpone until the 9th.

[gundalow]

The 2.5 freeze dates (merge deadlines) have been pushed out by a week.

Please see updated dates
https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_5.rst

To see whats change please see https://github.com/ansible/ansible/commit/1826c27e6841eb313dc3a05dc7f19c96e42c7fbf

[dagwieers]

---

This agenda has been migrated to a new location: #294

---