Passing params/references to groups/adapters

[SteveL-MSFT]

Summary of the new feature / enhancement

dsc only has visibility in the top most layer. This means that functions that get called such as parameter() and reference() can only access those within the same layer. A group can access those functions, but only within that group's layer.

Currently, there isn't a way to pass parameters to groups and a group cannot access a reference outside of its layer.

Proposed technical implementation details (optional)

I think we are ok to say that reference only works within a group, but I can see utility in passing parameters lower. In the case of groups, we could define a new to pass parameter values with the expectation that the either the group has a literal parameters section it resolves or we can have it inherit the parent's parameter definitions.

For adapters, we may just not have support for either.

[SteveL-MSFT]

With this PR #385, we can define a new Arg type to indicate passing parameters and another for parameter values which the group resource or adapter can use. In the case of the PS-Adapter, it could then define a global $DSCParameter hashtable that could be used with PS resource properties that get resolved before passing to the PS resource.

[michaeltlombardi]

I think for long-term functionality, we may need to think about a way to reference nested instances. Consider the following cases:

• I have a configuration that depends on platform information returned by Microsoft/OSInfo - I need to have slightly different handling depending on the output from the operating system family. For the configuration to be settable, the Microsoft/OSInfo instance needs to be nested in a Microsoft.DSC/Assertion group instance, but I then can't reference the value.

  In this case, my options seem to be

  1. To move the problem up a layer, pre-filtering my machines to select which parameters to pass to my configuration document, or
  2. To customize a resource to handle looking up the platform information internally, instead of reusing the existing resource.

• I have a configuration that uses a mix of PSDSC resources and command-based resources. I can't retrieve any outputs from my PSDSC resources to use with my command-based resources. If I can't reference adapted resources from an instance outside of that adapter, I'm locked into using only resources for that adapter or rewriting them as non-adapted resources myself.

[SteveL-MSFT]

Part of the challenge would be bi-directional support so that raw result content can be sent up to a parent so that a sibling can access it.

[SteveL-MSFT]

Thinking about this further, I think groups can receive parameters from parent as described above. Siblings that need to reference results from a group can always reference the whole group and use dot-notation to retrieve the specific resource result within the group. So the bi-direction will be asymmetrical, but consistent within themselves.

[SteveL-MSFT]

I think the way to do this is to simply serialize the internal Context struct and pass it as a hidden parameter to dsc. This would be a new type of arg specified in the manifest that other resources can leverage. This also means the Context schema would need to be published, but would automatically cover parameters, variables, and references.

[SteveL-MSFT]

We need to support ARM output to make this more useful