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
{{ message }}
Repository navigation
Improve handling for non-enforceable resources in dsc config set #268
As a user, I want to define a configuration that includes a non-enforceable resources in my configuration document without needing to edit the document prior to calling dsc config set.
Currently, if a configuration document includes a non-enforceable resource outside of a DSC/AssertionGroup instance, the command raises an error during configuration validation. However, a configuration document that defines non-enforceable resources outside of an assertion group are valid for both get and test operations.
Users should be able to indicate at the resource level or command level that non-enforceable resources should be ignored for the set operation. If a confirmation model is adopted, DSC should offer users the choice to abort or continue the operation when the command is run interactively and the user didn't indicate how to handle non-enforceable resources explicitly.
This doesn't obviate the need for the DSC/AssertionGroup, which ensures that enforceable resources don't change system state during a set call.
A further consideration is whether non-enforceable resources should still be tested during a set operation. I think that it makes sense for DSC to test those resources and allow them to be referenced as dependencies for other instances.
In the past, we handled this in machine configuration by publishing two distinct packages. That way there was never a chance of forgetting a parameter and having an unintended outcome. Does that approach resolve this issue or is there more to consider?
An idea I had that could maybe be used to handle this scenario is a RetrieveGroup (name pending) which is like an AssertionGroup but instead of always running test, it always runs get for the purpose of using reference() to get information that would be passed to other resources for set and test.
Activity
mgreenegit commentedon Jan 23, 2024
In the past, we handled this in machine configuration by publishing two distinct packages. That way there was never a chance of forgetting a parameter and having an unintended outcome. Does that approach resolve this issue or is there more to consider?
SteveL-MSFT commentedon Jan 23, 2024
An idea I had that could maybe be used to handle this scenario is a
RetrieveGroup(name pending) which is like anAssertionGroupbut instead of always runningtest, it always runsgetfor the purpose of usingreference()to get information that would be passed to other resources forsetandtest.SteveL-MSFT commentedon Feb 6, 2024
Another consideration is to have dsc skip resources that don't implement
setand have an opt-in "strict mode" to fail vs the current behavior