PowerShell resource

[SteveL-MSFT]

Summary of the new feature / enhancement

Instead of building PS resource support directly into dsc, perhaps we should have a powershellgroup resource which knows how to find and invoke PS based resources. Benefits:

• can evolve independently of dsc
• more natural to have it have a property to specify 5.1 vs 7 (default) as it's part of the schema rather than a meta-property
• as a group based resource, it controls the lifetime of pwsh or powershell reusing it for the entire group. this also allows users who want process isolation to have multiple instances of this resource
• create a pattern that may be useful for python, ruby, etc... in the future of having a long running instance rather than a new process for each one

Additional work in dsc to support this:

• need a way for a resource to register in their json manifest that it's a "resource provider" so that dsc resource list knows to call it and add it's resources to the output, but the schema would change to indicate that resource needs to be used within a powershellgroup.

Proposed technical implementation details (optional)

No response

[michaeltlombardi]

I think this would be a great option and could really help for ruby/python/node resources. If I understand this proposal correctly, this is for being able to define a provider and have resources indicate that they belong to that provider?

I think that's a much more maintainable model than the Puppet providers, where you had one "resource" that could have many backends (so I could write a file provider for Windows that reuses the same resource configuration surface as the one for Unix). My experience working on those is that the differences between providers became complex enough that we would've been better off having separate resources.

If the intent is "make it much easier to call resources written in interpreted languages without full overhead for each resource" then I think this is a stellar idea.

[SteveL-MSFT]

@michaeltlombardi yes, this type of resource would indicate in their manifest it's a "provider" of resources (I'm certainly open to other names) in that discovery would call these types of resources for enumeration.

As you noted, other languages with runtimes (basically any script-based language) would control their own lifetimes rather than spinning up a new process for every resource of that type. You got the intent correct, but I think it also solves other problems. In the case of Python, you can imagine a Python2 resource vs a Python3 resource or perhaps just a Python resource that had a property indicating the version.

[SteveL-MSFT]

In this specific case, I would think this PowerShellGroup resource would be written in C# and could host the .NET CLR, but there would be problems between 5.1 and 7. Shelling out to a long lived powershell.exe and pwsh.exe may be simpler although the continuous interaction with those processes via STDIN and STDOUT would be more complex.

However, whether we decide this is the right direction should be independent of the engineering work until proven otherwise :)

[anmenaga]

2 thoughts on this: 1) This steps onto the territory of a "resource provider" concept in dscv3. So I'd prefer that this functionality to be generic enough so it can be used by other "resource providers" - API and interaction protocol "dscv3 <-> a resource provider" clearly defined; Then PS Classic resource provider can be an example for that. 2) I'm fine with PS Classic resource handler to be implemented this way eventually; but as a first step it probably should be in dsc.exe Once the interface for resource providers becomes clear, it can be moved into a separate resource provider.

[SteveL-MSFT]

@anmenaga an additional benefit of this approach being outside of dsc itself is that it can be implemented in C# instead of Rust which should make it faster to develop. In this case, I'd imagine we'd have a psdsc executable (name pending) that exposes both a DSC/PowerShellGroup and DSC/WindowsPowerShellGroup resources. For execution, the only difference is that DSC/WindowsPowerShellGroup would call psdsc with a switch to indicate it should use powershell.exe instead of pwsh.exe (the default)

[michaeltlombardi]

One other question this raises for me is what it looks like when I want to call dsc resource foo for a PowerShell DSC Resource - does that need to be nested in a DSC/PowerShellGroup Resource?

[SteveL-MSFT]

@michaeltlombardi that is true for any group resource, but presumably psresource (or whatever we call it) would expose that capability if you don't want to craft a config for it or we could say you just use Invoke-DscResource for direct execution.

[mgreenegit]

Two things this made me think about:

1. There is a long standing ask for resources to pass output/input from one to another. Could this work within a group, and then have the group pass through selected output to the next group or resource in a config?
2. Would it make sense for groups to support a reference to an external file for composability?

Thinking this not this