dsc get fails when using powershellgroup resources

[jchancellor-ms]

Prerequisites

• [X] Write a descriptive title.
• [X] Make sure you are able to repro it on the latest version
• [X] Search the existing issues.

Steps to reproduce

Based on powershell sample here - (https://learn.microsoft.com/en-us/powershell/dsc/reference/psdscresources/resources/windowsfeature/example?view=dsc-2.0) - Invoke-DSCResource 's get method only accepts a subset of the properties and isn't smart enough to throw the unnecessary items away.

This results in errors similar to the following: "Get-TargetResource: A parameter cannot be found that matches parameter name 'Ensure'" when running dsc get.

I was able to work around this temporarily by adding the following code to the powershellgroup.resource.ps1 file after line 165. However, a more formal fix should probably be reviewed to determine if things like Credentials need to be retained and how to get them for each resource type.

$nonGetProperties = ((Get-DscResource -Name $ResourceTypeName -Module $ModuleName).Properties | where {$_.IsMandatory -eq $false}).Name foreach ($property in $nonGetProperties){ $inputht.remove($property) }

My config yaml file is as follows:

# example.dsc.config.yaml
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
resources:
  - name: powershell-dsc-resources
    type: DSC/PowerShellGroup
    properties:
      resources:
      - name: DNS 
        type: PSDscResources/MSFT_WindowsFeature
        properties:
          Name: DNS
          Ensure: Present`

Expected behavior

dsc get should complete discovery of the resource

Actual behavior

Error: "Get-TargetResource: A parameter cannot be found that matches parameter name 'Ensure'"

Error details

"Get-TargetResource: A parameter cannot be found that matches parameter name 'Ensure'"

Environment data

Name                           Value
----                           -----
PSVersion                      7.3.9
PSEdition                      Core
GitCommitId                    7.3.9
OS                             Microsoft Windows 10.0.20348
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Version

7.3.9

Visuals

No response

[anmenaga]

This PR by Michael should fix this problem.

[michaeltlombardi]

This behavior is specific to mof-based PSDSC Resources. It's actually both a very common and a very frustrating problem for integrating with legacy PSDSC resources, even in v1.1. From an API contract perspective, the root problem is that the implementation of the MOF-based resource doesn't respect its declared API surface:

1. The *-TargetResource functions for a resource should all have the same parameter block definition.
2. That parameter block definition should map exactly to the *.schema.mof for the resource.

In the case of WindowsFeature, the Get-TargetResource function only accepts Name and Credential. The difficulty in managing this from any integrating tools is that the integrating tool can't rely on the declared resource schema when interacting with resources. You have to implement additional processing, like inspecting the Get-TargetResource command to get the available parameters.

I ran into this when I was working on Puppet.Dsc and came to a similar workaround, which to be clear: is actually not a reliable workaround. It depends on the PSDSC resource not using any non-mandatory properties in the Get process. However, it's the only way I found to avoid unexpected errors when calling get for MOF-based resources.

[jchancellor-ms]

That makes sense. Is the overall strategic intent for resource content to be refactored in new languages with strong API contracts? Selfishly, I'd like the end result to be a lot like how Terraform behaves with the executable managing implementation graph ordering, config file parsing, resource exectuation, and downloading and managing the resource providers. I also like that they have 'official' resource providers owned by the corporate partners.

[michaeltlombardi]

DSCv3 definitely aims to have stronger API contracts. General command-based DSC Resources, which can be authored in any language - a go binary, a python script, a bash script, a sub-command for a dotnet CLI tool - are required to define a JSON Schema that is used as the API contract for the resource properties. DSC can then validate the data a user passes in before sending it to the resource and, equally important, validate the data a resource returns against that schema.

[jchancellor-ms]

@michaeltlombardi and @anmenaga - Is there a timetable on the alpha.4 or alpha.5 release? I'm trying to do a very early demo with my customer to get feedback on what they would like to see as well as talk through the current concept and all the examples I've tried so far fail when using the alpha.3 release.

[michaeltlombardi]

@jchancellor-ms - We've started the release process for alpha.4. No firm timeline for alpha.5 at this time.

[SteveL-MSFT]

@anmenaga this still fails, but not because of the property, but MSFT_WindowsFeature isn't found even though get-dscresource finds it