You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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
To move the problem up a layer, pre-filtering my machines to select which parameters to pass to my configuration document, or
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.
Summary of the new feature / enhancement
dsc
only has visibility in the top most layer. This means that functions that get called such asparameter()
andreference()
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.
The text was updated successfully, but these errors were encountered: