Open michaeltlombardi opened 10 months ago
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
.
Another consideration is to have dsc skip resources that don't implement set
and have an opt-in "strict mode" to fail vs the current behavior
Summary of the new feature / enhancement
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 bothget
andtest
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 aset
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.Proposed technical implementation details (optional)
No response