PowerShell provider backend

Use Case

Provide a Windows-native way to build providers.

Describe the Solution You Would Like

This will need more technical investigation, but might enable a new set of developers for windows-specific content.

Would it be feasible to build a powershell "thing" that can take and return the data structures created/required by the get/set methods on the regular ruby provider?

Building something powershell-native is much more appealing to folks than building the ruby bridge code. In the end, if we can agree on a exchange format (basically JSON with the correct shape), a windows admin would only need the type on the puppet side, like this:

Puppet::ResourceApi.register_type(
  name: 'patch_win',
  docs: <<-EOS,
      This type provides Puppet with the capabilities to manage ...
    EOS
  features: [ powershell ],
  implementation: 'PatchWinProvider',
  attributes:   {
    ensure:      {
      type:    'Enum[present, absent]',
      desc:    'Whether this resource should be present or absent on the target system.',
      default: 'present',
    },
    name:        {
      type:      'String',
      desc:      'The name of the resource you want to manage.',
      behaviour: :namevar,
    },
  },
)

and no ruby code at all, but in a pinch, we can likely generate that at build/dev time from the powershell code too.

Questions that would need to be solved (in order of my lack of knowledge):

• How would that ps1 file be distributed? It should go into the module (and maybe would get plugin synced), but I'm very unclear of how that will work together with everything.

• Does the powershell parts need to store any ephemeral state between get and set? "No", would be the much simpler answer. If yes, I fear that we'd need some serious mangling in the back-end.

• automatically keeping the ruby type info and the powershell implementation in sync. – depending on the details on the powershell side, and customer's needs, this could be as simple as not mattering at all, or as complex as autogenerating the type information from the powershell code on every commit and checking on appveyor (or other CI) that it is up-to-date.

• Implement a bridge using the powershell manager from [https://github.com/puppetlabs/puppetlabs-powershell] to bridge requests back and forth. – This one seems to be pretty straight forward, as it only involves very small commands to trigger the powershell implementation and rendering/parsing JSON back and forth.

Additional Context

Originally filed as https://tickets.puppetlabs.com/browse/PDK-1064.

Start by investigating how the Ruby provider get/set methods exchange data and how the puppetlabs-powershell manager could invoke PowerShell and render or parse JSON. Resolve distribution and plugin-sync handling for the ps1 file, state requirements between get and set, and how Ruby type information stays synchronized; done means these design questions have an agreed implementation path.