ResourceManifest::Get should be optional

[anmenaga]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

With addition of Export functionality, that may be the only functionality that a resource implements;
however currently specifying 'Get' in the manifest is mandatory, which produces an error if resource does not support it:

PS C:\DSCv3> dsc resource export -r Microsoft/ProcessList
Error: Manifest: C:\DSCv3\bin\debug\process.dsc.resource.json
JSON: missing field `get` at line 9 column 1

Expected behavior

NA

Actual behavior

NA

Error details

No response

Environment data

NA

Version

v1

Visuals

No response

[michaeltlombardi]

Should get be optional, or should the manifest have a property like export that validates against a subschema like:

title:       Resource Exporting
description: |
  Defines whether the resource can be used to export instances. When this value is `true`,
  the resource is processed normally with the `dsc resource export` and `dsc config export`
  commands. When this value is `false`, the resource is ignored. When this value is `only`,
  the resource is invalid for other operations, like `get` and `set`.
type:    [boolean, string]
enum:    [true, false, only]
default: false

And then an export-only manifest would define as either:

1. Top-level keyword:

   {
     "export": "only",
     "get": {
       // get definition
     }
   }

2. Keyword in get:

   {
     "get": {
       "export": "only",
       // get definition
     }
   }

Are there times where we would expect the export to be something different from get, except for whether instance properties are passed to the resource? Do I have to define export and get fully to support both, or can I do something like this?

{
  "get": {
    // get definition
  },
  "export": true
}

Instead of:

{
  "get": {
    // get definition
  },
  "export": {
    // same as get definition
  }
}

Edit: I'm also unclear on when you would define an export-only resource. When would I want to export instances of the resource I can't validate (if there's no get for a specific instance, I don't see a coherent way to synthetically test every instance, especially for ephemeral instances) or enforce?

[SteveL-MSFT]

It's also not clear to me a real example where a resource would only support export. It means it can't be used for auditing and if it implements export, it shouldn't be much more to support get.