PowerShell provider backend

[DavidS]

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.

[DavidS]

@kreeuwijk commented:

The .ps1 file would go in the same folder as the .rb file for a provider, e.g. /lib/puppet/provider//.ps1
It would be plugin-synced the exact same way.

The existing PuppetX::PowerShell::PowerShellManager could probably be leveraged to instantiate the custom provider on the client.

Similar to the Ruby-based provider, the Powershell-based provider should have initialize(), get(), create(), update() and delete() functions defined in its code. The Resource API can then instantiate the provider and interact with it through the Powershell pipeline, calling functions as needed.

Communicating context updates back to Puppet is going to be the tricky part. This would probably require some sort of Powershell runtime environment created by the Resource API that is aware of the provider's context, and provides methods to the .ps1 script for updating & setting state context.

Defining the type in Ruby is comparatively easy vs the defining the provider, so that's not a high priority issue today. Autogenerating the type from the provider would be a nice-to-have, but then more as a generic capability of the Resource API, not only for the Windows-platform specifically.