I have just started to look at using Ansible as the orchestration engine for DSC resources on Windows; Ansible modules for Windows are a bit too thin on the ground at the moment. I have found a couple of options both developed by Trond Hindenes: one is a wrapper module that invokes DSC expressions (https://github.com/trondhindenes/Ansible-win_dsc) and another is a script that generates Ansible modules from DSC resources (https://github.com/trondhindenes/AnsibleDscModuleGenerator).
I was wondering if anyone had insight into whether this or something similar is in the pipeline for the main Ansible release? I might be wrong but Ansible support doesn’t look to be a priority, and listening to a recent-ish powershell.org podcast with someone from the Ansible team I didn’t get the feeling that fuller Windows/Powershell/WMF functionality was at the heart of the roadmap (or particularly easy to implement!).
That was me. Exploring “first-class” DSC support is on the Ansible 2.4 roadmap (still in draft), but we haven’t yet committed to what form it will take. If you’ve got opinions, or want to “grab a shovel”, please stop by a Windows Working Group IRC meeting- we’ll probably start discussing that kind of stuff once 2.3 has shipped.
Thanks for the reply. I hope you didn’t take my comments re: your appearance on the podcast as a criticism! I understand that Windows doesn’t really fit cleanly with your current implementation and that there are significant decisions to be made.
Matt’s insight regarding the roadmap is very useful, however is anyone using the win_dsc5 module in the wild? I am due to start some testing today so if there are any glaring gotchas that I can avoid please do share - it will be much appreciated.
I’m actually getting a steady trickle of prs and feedbacks on the dsc-related stuff I wrote - which is great!
These were written when dsc still was a bit flakey and more than anything as proof of concept pieces. But yeah, we run these things in production - and they work really great. I haven’t made any effort to get them merged in to main, mostly since Ansible’s “main” powershell requirement is for psv3 and my modules require psv5.
Happy to submit them tho, but that would mean that we (as in the Ansible project) first take an “official” stance on powershell version support. eg, do we allow v5-only modules into ansible core?
Big-picture, I have no problem shipping modules that require a greater Powershell/Windows version than our baselines if they’re baked on tech that requires it. No sense in keeping Ansible in the relative “dark ages” and ignoring all the great stuff that’s happening in the PS community around DSC and other things. However, before we open the door to that, I want to make sure that we’ve got clear and consistent ways to both document the requirements, and to fail clearly when they’re not met.
In 2.4, we’ll be using Powershell’s native #Requires syntax to drive module imports and PS version testing (but ATM we have to roll our own checking for it), so the runtime failure side should be covered. We just need to extend the doc metadata and rendering to show that it has external requirements beyond our baseline stuff. Off the top of my head, I think we already have a requirements keyword, but can’t remember how/if it renders to HTML.
The other to-be-solved issue that might hold up meaningful DSC support in Ansible proper is around generated modules- we’ve thus far been very resistant to ship them in the box, as PR/change/attribution are very problematic. We’re still juggling options around external module hosting, which might be one way to solve that, but at least currently, we’re saying “no” to shipping generated modules in the box with Ansible.
Would shipping a module generator be a viable way around this?
Once you start doing anything you care about, you need to pick a version of ansible and test with it before using it in production anyway, so having an extra step where you generate the modules you are going to test with and keep them in your /library (probably in source) control, would seem reasonable to me.
Its my impression that the win_dsc5 module is far more popular than the “auto-generated” stuff. win_dsc5 simply looks at the underlying dsc resource at execution time, maps the parameters and injects the things - so its essentially just a shim. The ModuleGenerator stuff is more of a moving target, so that one would probably not be the best of ideas to include in core.
I’d be mroe than happy to pr the win_dsc5 module (probably rename it to win_dsc) and get some community contribution on it in order to increase its quality and robustness.
I’m definitely open to shipping the dynamic DSC executor module as a big first step (and maybe the only one?), so if you want to polish it up and PR it for 2.4, please do! Agreed WRT the name change to remove the version- DSC4 is pretty worthy of ignoring IMO.
Exploring “first-class” DSC support is on the Ansible 2.4 roadmap (still in draft), but we haven’t yet committed to what form it will take. If you’ve got opinions, or want to “grab a shovel”, please stop by a