Jira (BOLT-1429) Inconsistent behavior in Boltspec::Run.run_command on Windows

22 views
Skip to first unread message

William Hurt (JIRA)

unread,
Jun 26, 2019, 2:06:03 AM6/26/19
to puppe...@googlegroups.com
William Hurt created an issue
 
Puppet Task Runner / Bug BOLT-1429
Inconsistent behavior in Boltspec::Run.run_command on Windows
Issue Type: Bug Bug
Assignee: Unassigned
Components: bolt, Windows
Created: 2019/06/25 11:05 PM
Labels: bolt windows
Priority: Normal Normal
Reporter: William Hurt

When the WinRM transport is used with the run_command method, Bolt leverages the WinRM gem and deliberately chooses to create a PowerShell session on the remote host.

Using the local_windows transport to execute commands on the local host however is different. A simple call to Open3.capture3 is made.

The effect on the end user is that the behavior of commands given to run_command is inconsistent.

Litmus for instance exposes a method called `run_shell` that ends up leveraging `run_command`. Users that want to test their module using Litmus would be forced to detect within their test suite which scenario they are in at run time, local or remote, and if local, wrap their own commands in `powershell.exe -noprofile -command #

{blah}

` boilerplate on their own.

Instead, since the better default choice has already been made for WinRM transport commands, it seems like it could solve the issue closer to the source if the local transport were made to implement it's own wrapper, so that all consumers of the `run_command` method in Bolt spec, whether they be end users or frameworks, could enjoy consistency in the behavior of their commands.

As an example of users already affected see this PR comment in which we are already faced with this difficulty while converting a module's test suite to Litmus.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

William Hurt (JIRA)

unread,
Jun 26, 2019, 2:08:02 AM6/26/19
to puppe...@googlegroups.com
William Hurt updated an issue
Change By: William Hurt
When the WinRM transport is used with the run_command method, Bolt leverages the WinRM gem and deliberately chooses to create a [PowerShell session on the remote host|https://github.com/puppetlabs/bolt/blob/master/lib/bolt/transport/winrm/connection.rb#L54].

Using the local_windows transport to execute commands on the local host however is different. A simple [call to Open3.capture3|https://github.com/puppetlabs/bolt/blob/master/lib/bolt/transport/local_windows.rb#L71] is made.


The effect on the end user is that the behavior of commands given to run_command is inconsistent.

Litmus for instance exposes a method called
` run_shell ` that ends up leveraging ` run_command ` . Users that want to test their module using Litmus would be forced to detect within their test suite which scenario they are in at run time, local or remote, and if local, wrap their own commands in ` ' powershell.exe -noprofile -command #{ < blah }` >' boilerplate on their own.


Instead, since the better default choice has already been made for WinRM transport commands, it seems like it could solve the issue closer to the source if the local transport were made to implement it's own wrapper, so that all consumers of the `run_command` method in Bolt spec, whether they be end users or frameworks, could enjoy consistency in the behavior of their commands.

As an example of users already affected see [this PR comment|https://github.com/puppetlabs/puppetlabs-dsc/pull/414#discussion_r297455284] in which we are already faced with this difficulty while converting a module's test suite to Litmus.

Cas Donoghue (JIRA)

unread,
Jun 26, 2019, 10:37:03 AM6/26/19
to puppe...@googlegroups.com
Cas Donoghue commented on Bug BOLT-1429
 
Re: Inconsistent behavior in Boltspec::Run.run_command on Windows

Perhaps we need an option where this is a setting in the local transport? For example something like

config:
  transport: local
    local:
      shell-command: powershell.exe -noprofile -command

Similar to what we have done for the docker transport. https://puppet.com/docs/bolt/latest/bolt_configuration_options.html#docker-transport-configuration-options

Cas Donoghue (JIRA)

unread,
Jun 26, 2019, 10:41:04 AM6/26/19
to puppe...@googlegroups.com

William Hurt (JIRA)

unread,
Jun 26, 2019, 10:47:02 AM6/26/19
to puppe...@googlegroups.com
William Hurt commented on Bug BOLT-1429
 
Re: Inconsistent behavior in Boltspec::Run.run_command on Windows

I think I could live with an option like this as long as the powershell command is the default option, with cmd /c configurable as needed for a specific use case.

Alex Dreyer (JIRA)

unread,
Jun 26, 2019, 11:22:03 AM6/26/19
to puppe...@googlegroups.com
Alex Dreyer commented on Bug BOLT-1429

This feels like a bug, we should verify in slack that no one is relying on this behavior though. If not I don't think we need to expose a shell-command option yet.

Yasmin Rajabi (JIRA)

unread,
Aug 27, 2019, 2:46:03 PM8/27/19
to puppe...@googlegroups.com

Thomas Honey William Hurt Glenn Sarti hey is this something you find important and want to take on?

William Hurt (JIRA)

unread,
Aug 27, 2019, 2:57:04 PM8/27/19
to puppe...@googlegroups.com
William Hurt commented on Bug BOLT-1429

Yasmin Rajabi I think Michael Lombardi is zeroing in on a ruby gem based solution that you might like. His solution would allow multiple powershell commands in the same run utilizing the same PowerShell process that is kept running between commands so that the process only needs to go through startup once per Bolt startup.

Alex Dreyer (JIRA)

unread,
Aug 27, 2019, 3:59:03 PM8/27/19
to puppe...@googlegroups.com
Alex Dreyer commented on Bug BOLT-1429

Would that be implemented for winrm too? I'm concerned about state being left around in some cases but not others.

We also originally had concerns about us not being able to manage that state reliably,

Glenn Sarti (JIRA)

unread,
Aug 27, 2019, 11:06:03 PM8/27/19
to puppe...@googlegroups.com
Glenn Sarti commented on Bug BOLT-1429

Yasmin Rajabi I feel it's still important. Having a different shell between local and remote commands is annoying (at best) and confusing.

Also adding "powershell.exe -noprofile -NoLogo -ExecutionPolicy Bypass -Command" as a workaround is far from a great UX.

Also using -Command has known peculiarities with regards to exit codes, double quoting, multiline commands etc. etc.

Using the PowerShell Process sharing gem (which powers the IIS, DSC, DSC_Lite and PowerShell Puppet module) is a much much better idea. Note that while it "shares" the same process, each execution is in it's own sandbox (PowerShell Runspace to be exact)

So I think this addresses Alex Dreyer's concern about "state" being left around.

As for Alex's comment about "Would that be implemented for winrm too?"
I don't understand the question. WinRM is a transport not a shell. What state in WinRM are you worried about?

Alex Dreyer (JIRA)

unread,
Aug 28, 2019, 11:18:03 AM8/28/19
to puppe...@googlegroups.com
Alex Dreyer commented on Bug BOLT-1429

It was specifically about saving the runspace between commands on winrm if we're going to on local. If we're not doing that I don't have any concerns.

Reply all
Reply to author
Forward
0 new messages