Consider how we might offer resource code as an ARM resource

[mgreenegit]

Summary of the new feature / enhancement

The intention would be for DSC resources to be published as an ARM resource. The motivation for such as solution would be to eliminate the machine configuration dependency on external artifacts, by modeling resources in ARM and writing them as a control-plane API.

This might be workable, based on Run Command resources. In that model, the script reference can either be in-line code or an external file. https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command-managed#rest-api

Proposed technical implementation details (optional)

For _very simple _one-liners__ we could consider passing in the command syntax with the parameter input. This probably would be most useful in audit scenarios. Set scripts are more often complicated but Get scripts can sometimes be quite short.

If we followed the Run Command schema, this is what the json might look like.

{
  "source": {
    "get": "$service = get-service -name $env:Name; @{Name = $service.Name; Status = $service.status}"
  },
  "parameters": {
    "Status": "Running",
    "Name": "bits"
  }
}

So an end-to-end automation command would look something like this.

{"source": {"get": "$service = get-service -name $env:Name; @{Name = $service.Name; Status = $service.status}"},"parameters": {"Status": "Running","Name": "bits"}} | dsc resource

This would require the machine configuration service team to create a new resource type under Microsoft.GuestConfiguration. Then a configuration in JSON format in ARM could reference the script code as a dependency.

[michaeltlombardi]

I think it would be really useful to be able to convert a resource manifest to the definition that ARM expects for a resource. That would keep the authoring considerations limited but expand the options for publishing/reuse/deployment.