PSDscResources/xPSDesiredStateConfiguration: Strategy and Roadmap Discussion

[mhendric]

Starting a new Issue to continue the discussion started in #131 regarding the strategy and roadmap for the PSDscResources and xPSDesiredStateConfiguration modules. Some (but not all) of the discussions started there:

-How do we reduce ambiguity to consumers of the modules where the same resource exists in both modules? -What is our strategy for porting fixes/features between resources (in either direction)? -Is there any way we can collapse these modules into a single module, and what would be required to do so? Or can we at least collapse overlapping resources into a single module? -What is blocking these from being collapsed? Supportability (from MSFT Product Groups)? Required OS or WMF versions? etc -What can we do (if anything) to address the above blockers? Feature branches / flags? Discontinue support for legacy systems? etc

[mhendric]

Tagging @andikrueger, @johlju, @PlagueHO , and @kwirkykat , from the previous discussion.

[tmeckel]

@mhendric quick question: my understanding about why these two, in many ways similar, modules exist ist the fact that xPSDesiredStateConfiguration is designed for PS 4.0 and PSDscResources only supports PS 5.0 and onwards. Is this correct?

[mhendric]

@tmeckel , that sounds like a good reason, although I'll defer to others to confirm or deny that. Either way I'll turn around and ask, do we want to support PS 4 forever, or do we want to set an end of life for it? The old versions of the module still exist on PowerShell Gallery. We could potentially stop supporting PS 4 in xPSDesiredStateConfiguration at some point, and add a disclaimer saying if you want to use PS 4, you must use one of the older versions.

I'm not necessarily saying this is the correct path to take, just an option.

A related question is, what are some cases we are aware of where people can't upgrade past PS4? As the maintainer of xExchange, I know the Exchange Product Group doesn't support upgrading past the major PS version that shipped with the OS. This is a problem for those running on Windows 2012 R2 or older. As such we need to keep maintaining support for PS4 in xExchange (although I've considered deprecating support for it similar to what I suggested above).

[mhendric]

Following up on this one after this weeks community call. What I understood on the call (anyone feel free to correct me if they heard differently) is that PSDscResources cannot currently accept breaking changes since it's an in-box Module that ships with Windows, and that there’s no known plans to allow breaking changes in the future. In my opinion, that leaves us with a couple options:

• Come up with a plan to port non-breaking changes from xPSDesiredStateConfiguration -> PSDscResources, and a plan to port any changes from PSDscResources -> xPSDesiredStateConfiguration
• Treat these as two completely separate modules with no overlap, and don’t bother trying to port changes between them
  • As part of this, and has been suggested previously, maybe we post a blog or some other content explaining where these modules overlap, where they don't, and why you may want to use one over the other.

In my opinion, it is going to become increasingly hard to keep the resources that do overlap between modules aligned if xPSDesiredStateConfiguration is allowed to accept breaking changes but PSDscResources isn’t. As such I'd probably lean towards the second option.

What does the community think?

[johlju]

I lean towards alternative 2.

[mhendric]

One other thing I think I may have heard on the call (or maybe it was just implied) is that since PSDscResources ships out of the box with Windows, the module is officially supported by Microsoft, meaning someone can call MS Support and get help with the module specifically, not just the DSC engine. That's opposed to a module like xPSDesiredStateConfiguration that has zero support outside of the GitHub community. So maybe that's a key differentiator we can use when explaining the differences between these. If you want to use code that's officially supported by Microsoft, use PSDscResources. If you're OK foregoing support to get the latest and greatest (hopefully) module, use xPSDesiredStateConfiguration.

And we'll probably need someone from the PowerShell team to confirm or deny the support stance mentioned above. @kwirkykat or @mgreenegit ?

[mgreenegit]

Let's start with making sure supportability is clear. Is there anything not covered by the explanation in the supportability guidance? https://github.com/PowerShell/DscResources/blob/master/Supportability.md

It sounds like what we really need is a community module where updates to built-in resources for WMF4 can be proposed, tested/validated, and published. We would then need to clearly document where everyone should expect to see new releases and why. Is that the problem to be solved or have I missed the intent?

[mhendric]

Hey @mgreenegit , sorry for the late response, been traveling all week. The intent with this latest conversation is about helping to clarify the differences between these two modules, and help people decide why they should choose one over the other. The topic has come up in many threads before where people are confused about the overlap. So we're thinking it may be good to have a document somewhere explaining the differences. I thought supportability might be a key difference. But the PSDSCResources module does not have any statement saying it's supported by Microsoft, so per the above guidelines, it doesn't have formal Microsoft support. Would you agree with that?

I don't know that anyone is explicitly asking for WMF4 support, we were just looking for differentiators between the modules. I think some were under the impression that xPSDesiredStateConfiguration was supposed to fully support WMF4, but that is no longer a key difference. While cleaning up xPSDesiredStateConfiguration, we happened to notice that not all resources actually work with WMF4 any more (MSFT_xDSCWebService is broken for instance). We've since documented this lack of support here.

[johlju]

Updated the text a bit.

@mgreenegit If PSDscResources is suppose to be the replacement for the in-box (built-in) resources. If PSDscResources module is installed they override the in-box (built-in) resources with the same name, thus not allowing breaking changes. Since this override is happening, then should it not be some sort of support from Microsoft? If that is not the case (as per the linked guideline), then why can't we do breaking changes in PSDscResources?

If we are allowed to make breaking changes in PSDscResources we could just retire xPSDesiredStateConfiguration and leave it as it is for WMF 4.0 users, and continue build on the PSDscResources instead with WMF 5.x and above support. Because that is what I think mainly what users expect- for additional functionality in xPSDesiredStateConfiguration to move over to PSDscResources.

If we can't do the above. Then maybe we could just rename all the resources in xPSDesiredStateConfiguration to remove the 'x'. But to do so we need to prefix all the resources with something, because...

1. The resources can't work side by side with PSDesiredStateConfiguration or PSDscResources if they have the same names.
2. So the resources do not override the in-box (built-in) resources with the same name. (not sure about this is correct?)

If we rename these resources with a prefix, we could either do

1. Rename the xPSDesiredStateConfiguration to something else (e.g. 'PSDsc').
2. Move all the resources over to ComputerManagementDsc, and move the xDSCWebService to a new repository (or maybe xWebAdministration).

If we can't do breaking changes on PSDscResources, then I suggest we add a prefix on the resource and move them over to ComputerManagementDsc.

[mhendric]

Just adding on to what @johlju is suggesting. One of the primary drivers for this whole conversation was to figure out if we can actually reduce overlap between these modules, which would reduce a lot of effort required to maintain two similar but slightly different modules. After the last community call, it sounded like that wasn't possible due to the no breaking change stance. But I'll re-ask what @johlju did. If PSDSCResources isn't actually supported by Microsoft, then why can't we do breaking changes, which itself could allow us to collapse these?

[andikrueger]

Just adding some more thoughts to this conversation:

Why is PSDscResources using version 1 and no proper versioning settings? In case we would allow to change the version string for PSDSCResources then we would be able to add breaking changes.

For all those who update PSDscResources, it would be great when they would add the version string to their configurations.

From an development perspective - especially in cases someone uses DSC in mind with documentation as code - it's important to have proper versioning. Even right now with not allowing breaking chances in this repo, it is very negligently for all users as there is no chance to get a deeper understanding of these resources in cases they behave differently on several systems due to not documented module updates.

[johlju]

Not sure what you mean by version 1. This module is in version 2.1.0.0 and the changes is documented in the change log https://github.com/PowerShell/PSDscResources/blob/dev/README.md#versions

I’m not following you I think 🤔

[andikrueger]

Thank you for the clarification. This was my bad. I got totally confused by all the “no breaking changes” and “overrides the build-in resources from‘PSDesiredStateConfiguration’” and the wiki page with an import statement w/o a versionImport-DscResource -ModuleName PSDscResources”. On the other hand this shows one more time how misleading everything can be.

[johlju]

No worries. Agree it’s confusing.

It should have been version 2.10. It seems this module started at version 2.0 (at least according to the change log).