search

ansible / community

This repository is being archived. See https://github.com/ansible-community/presentations and https://github.com/ansible-community/meetings for the new locations
Apache License 2.0
489 stars 144 forks source link

Windows Working Group agenda - 2022 #644

Closed nitzmahone closed 1 year ago

nitzmahone commented 2 years ago

Github windows issues Github windows PRs Windows agenda Windows pinboard

The Windows Working Group is focused on improving Ansible's management of Windows hosts. We meet 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 2021 agenda #581)

briantist commented 2 years ago

A while back I talked about a hackathon project I did to get PowerShell modules able to execute locally with pwsh, so they could be run on the controller. That was accomplished with a modified version of the local connection plugin, and powershell shell plugin, and one slight modification to Ansible.Basic.cs.

We've been using this extensively locally with a collection focused on SQL Server created by @lowlydba , where the modules are all written in PowerShell with dbatools, and make connections to the SQL server directly, so they do not require being run a Windows host.

I'm helping @lowlydba make that collection public, and it's brought back the idea of using this connection/shell plugin to more easily run integration tests for the collection.

He's got a PR up to add them into the integration tests, but I wanted to also explore the possibility of including them in community.windows.

This diff https://github.com/LowlyDBA/lowlydba.sqlserver/pull/4/commits/e8e85567a2887079fc2d22f1c5442ba34076d7d6 shows the modifications to the 3 files to show what they look like.

The most intensive change is the hackery to inject the modified Ansible.Basic.cs, however I think that module util could be modified easily so that the above hackery isn't needed. The change it needs is to be able to not log to the Windows event log on non-Windows systems, so instead of commenting it out, I could come up with that as a separate change.

That would make the resulting connection/shell plugin changes pretty trivial. They may need a little more work to make them production ready, which could be done via PR review and revisions, if accepting them would be amenable in the first place.

I have also considered putting them in a separate collection, but it's a tad overkill for two plugins that are basically edits of ansible builtins; still it's a possibility.

Edit (jborean93): As discussed in the WG - The changes for Ansible.Basic.cs to enable this will be implemented in https://github.com/ansible/ansible/pull/76924#pullrequestreview-869850663. The connection and shell plugins are recommended to be stored in their own collection for now. Supporting this scenario officially will require a fair bit of work and having this temporary method in is not something we wish to include in ansible.windows or community.windows for now.

jborean93 commented 2 years ago

No meeting this week due to nitzmahone and I being unavailable

jborean93 commented 2 years ago

There's a few new modules in a PR to community.windows https://github.com/ansible-collections/community.windows/pull/379. We really need to come up with a future solution to what will be accepted in that collection when it comes to new modules. So far I see the following options

Every new module being added adds more of a maintenance burden on myself and due to the community nature of the collection I don't give it the time that is really needed. I personally sit on option 2 that would allow things like https://github.com/ansible-collections/community.windows/pull/379 but not new additions like and IIS module https://github.com/ansible-collections/community.windows/pull/366 or a domain module.

Regardless of what is chosen I think contributions need to be expanded in the README to reflect the slowness of updates and how issues aren't addressed directly by myself but by anything wishing to contribute bugfixes.

briantist commented 2 years ago

We discussed in the past enabling docs build and publishing for the Windows collections, starting with community.windows.

The docs build project finally has a GitHub Pages publishing workflow, so this can be enabled easily.

This can also completely take the place of manual RST generation and remove the RSTs in the docs/ folder, so we can also do away with the workflow I put up for alerting PR authors on edits.

I can put up the PR to add the needed workflows and clean up the RSTs (it won't take long but I won't be able to get to it until after the meeting). There are now sample workflows that can be used by collection maintainers: https://github.com/ansible-community/github-docs-build/tree/main/samples

The PR I'd put up would use the two gh-pages variants seen there (the only thing that needs to change in those are the collection name/URLs).

The one thing I cannot do is enable GitHub Pages in preparation for that. There is a guide in the docs build wiki for how to set it up for the first time: https://github.com/ansible-community/github-docs-build/wiki/Getting-started-with-GitHub-Pages

Examples from collections using it now:

An open (at the time of this writing) PR where you can see the comment that gets posted which links to rendered versions, etc.:

UPDATE: we'll enable this for push to main for now- still some overall security concerns with allowing PR workflows anywhere near a write token for the main repo- that might be addressed in the future by writing to a separate shared surrogate repo via a PAT, possibly with submodule refs to allow the docs to appear in the primary repo.

briantist commented 2 years ago

EDIT (nitzmahone): needs discussion on best home (maybe ansible.windows)- bring up in next DaWGs meeting?

briantist commented 2 years ago

The ansible.windows version of the docs build stuff.

I will be AFK all day for the 7/12 UTC meeting but probably not much to discuss on this one unless it should be separated (I'll see comments on the PR though).

jborean93 commented 2 years ago

The upcoming working group is cancelled as nitzmahone and I have the day off, see you all next week.

nitzmahone commented 2 years ago

(NO MEETING SEPTEMBER 6)

jborean93 commented 2 years ago

https://github.com/ansible/ansible/pull/78938 - Updates PSScriptAnalyzer to 1.21.0 and includes 3 new rules:

I've set up the PR so that AvoidSemicolonsAsLineTerminators is enabled and will require fixes in both Windows collections to pass. Will need to decide whether this is a rule we do want or whether to keep it disabled.

Edit: Consensus was to enable all 3 rules and fix up the problems in the repo.

jborean93 commented 2 years ago

No meeting on October 18th due to contributor summit.

briantist commented 2 years ago

Wondering about the next release date for c.w, specifically to get this fix out there: https://github.com/ansible-collections/community.windows/pull/425

EDIT: Jordan's planning a release for next week