`exporter` kind of resource about dsc

[denelon]

For the sake of visibility:

In the case of WinGet as an orchestrator, we have an experimental feature in place for generating configuration from the current state for a single resource or package (and resource). This works with a few DSC v2 resources, but it's more of a building block to work on top of today.

In the future, WinGet would iterate over all installed packages, and it would be aware of Windows Settings.

Dev Home also has plans to support a logical "get my current configuration" and then some kind of editor type of experience to modify the generated configuration.

I think the approach here makes perfect sense in the world of DSC v3 only scenarios for DSC.exe, but in the current hybrid world, we're likely to see multiple different scenarios that need unique treatments.

[michaeltlombardi]

A few things I think important to note about any potential recursive export implementations:

1. Currently, DSC can only perform the export for resources that are already installed on the machine.

   In the future, with a repository for DSC resource packages, this could be runtime-resolvable. Right now, if you don't already have a resource installed and available, DSC simply can't know that it exists.

   For example, you might have a resource to manage the installation of an application with WinGet, but not that application's configuration resource(s). So the export would be able to ensure that the application gets installed at the right version, but it installs with the default config, not the current config.

2. I don't think that there's a good way, right now, for resources to indicate (and therefore, for the export function to propogate) the difference between "This instance is configured for property foo to be set to 1 and "This instance implicitly uses the default value 1 for property foo."

   This primarily matters when a resource or application updates. This can lead to a case where both systems seem to have the same configuration before an update, but after updating the systems have different behavior - and from the perspective of the user, they only changed the exact same thing on both systems.

3. I don't see a good way, without custom implementations for the exporters, to map dependencies between exported instances.

   I don't see how DSC itself (or higher order tools/exporter resources without custom logic) can tell that a package resource instance and a configuration file resource instance are related. With no way to define dependencies, you can end up with a configuration that tries to configure an app that isn't installed, or a web server before the database is defined, etc.

4. I'm not sure I see a coherent way for the exporter to handle groups.

   Similar to dependencies, there's no way to associate a set of resources together, except through an adapter or group resource - whereas for readability and dependency management I would probably want the application package, configuration, and service resource instances grouped together.

I think recursive export is a good idea, but there's limitations to the operation that I don't see feasible options for that won't require a lot of custom logic or new resource capabilities for.

I also think that we should always be very clear when we describe export-for-reuse operations that the output from that operation is a starting point and should always be inspected and approved by a human before using that output. Especially when we're thinking about recursively exporting the full configuration of a system, but even when exporting the current configuration of a small group of applications.

[SteveL-MSFT]

For the mapping of applications to resources, I think a SWID property in the resource manifest should be sufficient. SWIDs are XML, so I suppose this would be a string that contains XML. However, it does appear that SWID XML doesn't contain content and is only relying on attributes, so this could be converted to JSON.

It would make sense to have a property in the manifest for exporter kinds to declare if it returns and exportable config (which initiates recursion) or not (should be used directly to apply).