PowerShell resource about dsc HOT 8 CLOSED

@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.

from dsc.

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 :)

from dsc.

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.

from dsc.

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.

from dsc.

@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)

from dsc.

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?

from dsc.

@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.

from dsc.

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

from dsc.