Windows module_utils, module API

Archives Ansible Developer
1

Soliciting opinions about building a real Powershell Ansible module API, rather than continuing to bolt on ad-hoc stuff to module_utils/powershell.ps1…

Well-intentioned PRs like https://github.com/ansible/ansible/pull/12600/ add useful functionality, but we’re missing a holistic module API like Python has. There’s also significant overlap in what PS already provides (ValidateSet, type coercion, etc), too, but the built-in PS stuff doesn’t exactly give the friendliest feedback. Everything we add to powershell.ps1 that actually gets used becomes a de-facto API, which means it’s hard to go back in time and make something consistent. We’re treading ground that has already been well-covered by the Python stuff. My preference would be to start from scratch, using the Python Ansible module API as a starting point, and attempt to get feature parity and an API that’s shaped pretty much like its Python counterpart. The use of PSObject for args kinda hamstrings us in that regard- I’ve already prototyped replacing ConvertFrom-Json with the built-in JavascriptSerializer (which can give us a dictionary instead).

Thoughts? I’m sure we’re too late for 2.0, but if there’s appetite for this, I’m sure we could get it in for 2.1…

-Matt

2

Another good idea (for after 2.0).

I’d ask that whatever API we wind up with is versioned from the get-go so we can plan changes and give extras module owners time to switch to new versions of the API in the future.

Jon

3

I completely agree. That said, I don’t know the details of the python module, maybe we should start out by trying to come up with a requirements list?

I would not mind building this into a PS module which we place on the target node (if it doesn’t already exist), so that we wouldn’t have to send the same code blocks to target nodes each time we send a play to a node.

4

Any other thoughts on this?

5

normally we try to keep changes from breaking backwards compatibility,
if one of these is warranted we should make it a different function.

Most of the times we try to add an extra optional parameter that
defaults to the previous behavior.

I might be missing something as I don't see the change that adds
aliases as breaking compatibility.