Long running mode for DSC

[SteveL-MSFT]

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 has dsc.exe accept JSON commands to execute. Commands would be taken serially. Something of the form:

{
  "DSCRequest": {
    "id": "anything the client providers",
    "operation": "get",
    "configuration": { },
    "configurationFile": "path",
    "traceLevel": "info",
  }
}

Where the properties would match many of the dsc command line arguments. An additional:

{
  "DSCResponse": {
    "id": "returns what the client provides",
    "status": "completed"
  }
}

This would indicate that the operation completed or had an error (like Request was invalid).

Can also have a specific command like:

{
  "DSCRequest": {
    "operation": "exit"
  }
}

This would tell dsc.exe to clean-up and exit.

[michaeltlombardi]

As this mode will require JSON input/output, we'll also need to define JSON Schemas for the data.

A few clarifying questions:

1. Is this for providing an up-front array of commands to execute, or a mode where DSC listens to an endpoint (like waiting for input to a named pipe or similar) until it gets an exit command?

2. 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

3. Is part of the plan for long-running mode to take advantage of in-memory caching for resource discovery? For example, is it intended to be faster to have DSC in server-mode perform 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).

[SteveL-MSFT]

1. I think initially, it will be via stdin/stdout/stderr, but not as sending a large set of instructions. It would be 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).
2. yes, this would be a series of JSON lines each specifying the equivalent of the command-line.
3. In this mode, I would expect in-memory cache of resources, but I think that's not required for the first iteration, it's really to allow integrating software not to have to spawn 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)