Comments (13)
Maybe it's just a special arg defined for set
. Don't think we need it for get
and test
from dsc.
Based on most recent discussion, we still need to define schema for whatif
output, but we have a mechanism to tell supported resources to emit whatif
#218 (comment). For resources that don't support it, dsc
will have a generic message on calling the resources with some non-sensitive parameters
from dsc.
How would WhatIf be different than Test?
from dsc.
Maybe it's implemented via Test?
from dsc.
I would see them as distinct.
A test
operation on a file copy evaluates if the files at the destination match the files at the source.
A set --whatif
operation would run the set
script with the cmdlet bindings so the output would log everything that would happen if set
were actually running, kind of like a simulation.
from dsc.
@mgreenegit we need to think how this would be implemented and what result would be returned. If we require resources to implement it, then it's less likely to be supported. Ideally, we can extract it from the resource metadata in the manifest. A dsc config set --whatif
could just do a test and return only what changes would apply rather than test
today returning what is different. Perhaps additional optional metadata in the manifest could indicate more destructive operations (aka ShouldProcess) although in the case of the registry, for example, any overwrite would be considered destructive.
from dsc.
I'm not sure how this is different than Test. Is this something that exists in DSC today?
from dsc.
While Invoke-DscResource
doesn't have support for the WhatIf parameter in any version I have installed locally, the Start-DscConfiguration
cmdlet in Windows PowerShell 5.1 does.
from dsc.
I think in earlier versions of DSC the WhatIf parameter served a useful purpose, because the only information we got back from the Test
method was boolean true
/false
. In that model, running with WhatIf was the only way to get a sense of how your system would change without actually applying the changes and potentially changing system state.
In the new model, where Test
returns more useful information, like:
expected_state:
scope: machine
ensure: present
updateAutomatically: false
actual_state:
ensure: absent
scope: machine
diff_properties:
- ensure
- updateAutomatically
In this new model, WhatIf support is primarily a different view of the same data, which can be useful for reporting and other integrating tools that have conceptual support for WhatIf (for example, Puppet has a --noop
flag that does the same sort of thing).
Reusing the output from above, that might look something like (keywords/structure just examples, not proposals):
changes:
ensure:
from: present
to: absent
from dsc.
Agree with @michaeltlombardi
I'm a little concerned it will be confused with PowerShell whatif. Maybe we should call it by a different name?
from dsc.
I think there should be a separate stream with WhatIfMessages and in the absence of a Test implementation and Set implements SupportsShouldProcess, Test would call Set with -WhatIf, capture the WhatIfMessages and if any exist (indicating that something needs to get done) then return false.
I also think it would be nice if WhatIfMessages themselves could contain a compliant boolean so that as the set goes through what it would do, you can get positive compliance messages instead of the presence of a WhatIf message indicating non-compliance but not indicating to the user what items are compliant.
My experience is that Test and Set generally share a lot of code and look similar. Doing this would prevent the need for code duplication in the Test.
from dsc.
@dkattan trying to rephrase your comment to avoid PowerShell-specific implementation details:
- Resources should be able to emit structured messages that indicate what a resource would change during a
set
operation. - Those messages should describe the change, like
setting property 'foo' from 'bar' to 'baz'
, and include boolean value wheretrue
indicates that the property is already in the desired state andfalse
indicates that it isn't. - That those messages in
set
running in this non-apply mode (what-if, noop, whatever it gets called) could be an alternative to relying on DSC's synthetic test, where anyfalse
value in a message indicates that the resource instance is out of the desired state.
My experience is that Test and Set generally share a lot of code and look similar. Doing this would prevent the need for code duplication in the Test.
In v3 the implementation for the test
operation is only required when the resource's properties can't be evaluated with a case-insensitive equivalency check (DSC's built-in synthetic test). If a resource doesn't define test
, DSC handles it for them.
Specifically regarding the code duplication problem, I've updated the PowerShell documentation for authoring class-based resources such that the Test()
method always calls Get()
and the Set()
method always calls Test()
. The duplication of code across get/set/test is an anti-pattern. The new tutorial for implementing a command-based DSC Resource in Go doesn't implement test
at all, but does include logic in the set
command for only changing state if changes need to be made.
from dsc.
I'm a little concerned it will be confused with PowerShell whatif. Maybe we should call it by a different name?
Alternatives used by other tools include:
- Puppet as a noop mode, set with the
--noop
flag ornoop
metaparameter in an instance definition. - Ansible has a check mode, set with the
--check
flag orcheck_mode
in a playbook. - Chef has a why-run mode, set with the
--why-run
flag, though Chef recommends not using it, as described in their blog post Why "Why-Run" Mode Is Considered Harmful by Julian Dunn - essentially, that it isn't an effective tool for validating what a run will do or a substitute for compliance validation. - Salt has both a test and mock state that don't execute changes.
- Terraform has a plan command to show what an
apply
will do. - Pulumi has a preview command to show what an
up
will do.
Of these options, I think the semantics of preview
are most aligned with whatIf
- though it's worth noting that ARM does have the what-if functionality itself, so reusing that semantic seems okay to me. I do like the combination of having both a --what-if
flag and --confirm
flag, the latter showing the what-if output per-resource and prompting for a continuation.
It might be worth defining both whatIf
and confirm
boolean options for the resource, borrowing from Puppet and Ansible to have a per-resource alternate behavior:
resources:
- name: Only show what-if
type: Microsoft.Windows/Registry
whatIf: true
properties:
keyPath: HKCU\tailspin\updates
valueName: automatic
valuData: { String: enable }
- name: Show what-if, prompt to enforce
type: Microsoft.Windows/Registry
confirm: true
properties:
keyPath: HKCU\tailspin\updates
valueName: automatic
valuData: { String: enable }
I would expect:
confirm: true
to supercedewhatif: false
- Both to default to
false
for an instance declaration --confirm
and--what-if
to apply to every instance - probably overriding any explicitconfirm: false
orwhatIf: false
settings for instances.
from dsc.
Related Issues (20)
- Schema validation fails when using expression HOT 3
- REST API resource
- When using `-d` to pass in the config HOT 1
- wildcard search for resource no longer works HOT 2
- Enable `SkipGroup` reusing dsc.exe HOT 1
- `RunCommand` resource HOT 5
- Add `Methods` to table view for `dsc resource list` HOT 4
- Rename `providers` term to be `adapters` HOT 2
- Annotation on a DSC Resource regarding elevation requirements HOT 3
- `DSCConfigRoot` should be absolute and not relative
- Standardize built-in resource namespaces HOT 1
- Signing resource manifests
- Support for Credentials HOT 1
- DSC resource table change for `methods`
- Update `dsc resource list` output schema to include `methods` HOT 3
- `RebootRequired` resource
- Rename `DSCConfigRoot` environment variable to `DSC_CONFIG_ROOT` and handle existing value
- Error when the variable referenced with `envvar()` doesn't exist
- Tracing and progress get interleaved
- PowerShell Adapter changes
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dsc.