Open SteveL-MSFT opened 5 months ago
As this mode will require JSON input/output, we'll also need to define JSON Schemas for the data.
A few clarifying questions:
I could tell DSC I want to run the following commands by passing an array of JSON blobs:
dsc resource list
dsc resource get --resource Microsoft/OSInfo
dsc config test --path ./config_1
dsc config export --path ./config_2
dsc resource list * --adapter *
and then dsc resource list PSDscResources/Environment
than calling those commands in serial at the terminal? Or is that out of scope for the feature?From my perspective as a former engineer at an integrating vendor, I would initially be unlikely to use this functionality if the array always needs to be sent up front. In that case, I would probably prefer to write a plugin that reuses the information in resource manifests to call the resources in my own process management. The resource manifests and design contract should ensure that I can just map resource manifests to what my software needs to do.
On the other hand, I can see how this would simplify the integration with DSC resources, if I can always just operate on the return data that includes messages and errors from DSC instead of handling the stdout/stderr streams myself. And if I can open a long-lived DSC process to just send/receive commands and output, I would definitely do that. That's similar to how we wrote the integration between Puppet and PSDSC (we needed a long-lived PowerShell process to avoid the overhead cost of spinning up and down dozens of PowerShell procs just to run a single Invoke-DscResource
command each time).
request
->response
->request
->response
. This also means that all JSON input/output would have to be JSON lines unless passed in as a file path (updated example above).dsc
for every operation.In many ways, this would be a predecessor having dsc
run as a daemon/service (certainly not via stdin/stdout, but some client API)
Summary of the new feature / enhancement
For integration into other products, it would make sense to have a
dsc
long-running mode which can accept multiple operations and not exit the process.Proposed technical implementation details (optional)
Probably a
--server-mode
type switch that hasdsc.exe
accept JSON commands to execute. Commands would be taken serially. Something of the form:Where the properties would match many of the
dsc
command line arguments. An additional:This would indicate that the operation completed or had an error (like Request was invalid).
Can also have a specific command like:
This would tell
dsc.exe
to clean-up and exit.