New interop between Chef and PowerShell 4.0 (or higher)

[stuartpreston]

Description

This change provides a new way of working with PowerShell on Windows-based systems that support .NET Framework 4.0 and PowerShell 4.0 or higher (This is the out of box configuration included with Windows Server 2012 R2).

• The primary benefit of this approach is PowerShell is accessed through the Ruby process and not via shell_out.
• The output from PowerShell that is usually formatted specially for console but in the new case is coerced to JSON and available as a Hash.
• Files containing potentially sensitive data are not written to disk, they are sent via COM to the PowerShell engine.
• Errors that occurred during script block execution can be trapped and handled

What's included:

• Chef::Powershell class (require "chef/powershell")
• powershell_exec mixin
• Binary inclusion of COM interop component required in the Windows package.
• Registry keys required for operation added to the Windows installer package.

Example mixin usage

  outcome = powershell_exec("Get-WindowsFeature | where { $_.Installed -eq $true }")
  if outcome.error?
    outcome.errors.each do |e|
      Chef::Log.error e
    end
  else
    Chef::Log.info "Result: #{outcome.result}"
  end

NB: powershell_exec has been included in the Universal DSL mixin list, alongside the existing powershell_out

It should be noted a full install of Chef Client is required to test this due to the components being registered by Windows installer.

Check List

• New functionality includes tests
• All tests pass
• RELEASE_NOTES.md, has been updated if required (not required for bugfixes, required for API changes)
• All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/master/CONTRIBUTING.md#developer-certification-of-origin-dco

[tas50]

We should just say what the helper is. Sometimes you're deep in Chef errors and it's hard to see what spit the actual error out so you can fix your code.

[stuartpreston]

Yep you're right, I was struggling to find where we consistently apply this elsewhere, any recommendations?

[lamont-granquist]

This should probably just be powershell_exec(script) for now. I don't think options are being used at all here now and can safely be introduced later when there's actually options to use (and **options should get used rather than the last.is_a?(Hash) stuff which is probably some ruby 1.8 kludginess in shell_out which we've not yet dared to do away with). The array style passing of arguments on windows is also busted (i tried adding windows support once to bake the poise_shell_out helper directly into mixlib-shellout, but its complicated and brittle -- https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/).

[stuartpreston]

Yeah, I was following powershell_out's style of doing things here. I'll revert back to taking the single argument for now :)

[stuartpreston]

Ready for merge, the Travis failures with Chef Zero seem unrelated...

[tas50]

It would be nice to have a benchmark here so we could explain how fancy this new mixin is

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.