Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing params/references to groups/adapters #381

Open
SteveL-MSFT opened this issue Apr 3, 2024 · 3 comments
Open

Passing params/references to groups/adapters #381

SteveL-MSFT opened this issue Apr 3, 2024 · 3 comments
Labels
Issue-Enhancement The issue is a feature or idea Need-Review

Comments

@SteveL-MSFT
Copy link
Member

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 SteveL-MSFT added Issue-Enhancement The issue is a feature or idea Need-Review labels Apr 3, 2024
@SteveL-MSFT
Copy link
Member Author

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
Copy link
Collaborator

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Enhancement The issue is a feature or idea Need-Review
Projects
None yet
Development

No branches or pull requests

2 participants