"Packer" Ansible connection for WinRM breaks on Ansible 2.3.0

[trondhindenes]

packer version: 1.0
packer host: Ubuntu 16
builder type: amazon-ebs

Problem description:
Ansible 2.3.0 introduces a rewrite of the way it sends commands to winrm-based nodes. This causes the current "packer" connection plugin to fail.

Here's the relevant log output:

amazon-ebs: An exception occurred during task execution. To see the full traceback, use -vvv. The error was: +           ~~~~~~~~~~                                                                                                                                                       
amazon-ebs: fatal: [default]: FAILED! => {"changed": false, "failed": true, "msg": "The term 'Parse-Args' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correc
d try again."}                                                                                                                                                                                                                                                                            
amazon-ebs:         to retry, use: --limit @/home/ubuntu/packer_files/playbook.retry                                                                                                                                                                                                      
amazon-ebs:                                                                                                                                                                                                                                                                               
amazon-ebs: PLAY RECAP *********************************************************************                                                                                                                                                                                              
amazon-ebs: default                    : ok=0    changed=0    unreachable=0    failed=1                                                                                                                                                                                                   
amazon-ebs:                                                                                                                                                                                                                                                                               

It's probably a good idea to get in touch with Matt Davis at Redhat to discuss how to solve this, as he's responsible for the Windows stuff in Ansible core.

On the same node, running Ansible v 2.2.0 suceeds, so there's no doubt this is related to the WinRM rewrite in Ansible 2.3.0.

[bhcleek]

Thanks for the report. I can duplicate this and have dug in to try to resolve it. I'll reach out to Matt Davis shortly.

[bhcleek]

There doesn't seem to be anything we can do about this until ansible/ansible#25012 is released.

[Constantin07]

I do confirm as well that I was able to reproduce this issue. (latest devel branch, ansible 2.4.0)

[bhcleek]

ansible/ansible#25012, which resolves this issue, has been merged and is scheduled for release in 2.4. It's also in the current release candidates for 2.3.2 (re: https://github.com/ansible/ansible/releases).

[lawrence-c]

Is there an update to the Packer side for this to work with Ansible 2.4+?

[lawrence-c]

Hmm, I was having issues using Ansible 2.4.0, with similar issues here. Upgraded Ansible to 2.4.1 and also added the changes seen in #5162, and now it's working fine.

[lawrence-c]

Never mind, I still get some issues occasionally:

vsphere: An exception occurred during task execution. To see the full traceback, use -vvv. The error was: +   ~~~~~~~~~~~~~~~~~~~~
vsphere: failed: [default] (item={u'package_name': u'nsis'}) => {"changed": false, "failed": true, "item": {"package_name": "nsis"}, "msg": "The term 'win_chocolatey.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again."}

With more debug, on a different run...

vsphere: Using module file /Users/gitlabs/inf_orchestration_v2/venv_vsphere_pyvmomi/lib/python2.7/site-packages/ansible/modules/windows/win_chocolatey.ps1
    vsphere: <127.0.0.1> ESTABLISH SSH CONNECTION FOR USER: username
    vsphere: <127.0.0.1> SSH: EXEC sshpass -d57 ssh -o ForwardAgent=yes -o StrictHostKeyChecking=no -o Port=54753 -o 'IdentityFile="/private/var/folders/c7/8kvczj9j6m5db7jfh2cfmzsh0000gn/T/ansible-key014387674"' -o User=username -o ConnectTimeout=10 127.0.0.1 'PowerShell -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -EncodedCommand UwBlAHQALQBTAHQAcgBpAGMAdABNAG8AZABlACAALQBWAGUAcgBzAGkAbwBuACAATABhAHQAZQBzAHQACgAoAE4AZQB3AC0ASQB0AGUAbQAgAC0AVAB5AHAAZQAgAEQAaQByAGUAYwB0AG8AcgB5ACAALQBQAGEAdABoACAAJABlAG4AdgA6AHQAZQBtAHAAIAAtAE4AYQBtAGUAIAAiAGEAbgBzAGkAYgBsAGUALQB0AG0AcAAtADEANQAxADEAMwA2ADUAOQA3ADMALgAxADIALQAxADIAMwA1ADkANwAxADgANAAxADMANAAxADQAMQAiACkALgBGAHUAbABsAE4AYQBtAGUAIAB8ACAAVwByAGkAdABlAC0ASABvAHMAdAAgAC0AUwBlAHAAYQByAGEAdABvAHIAIAAnACcAOwAKAEkAZgAgACgALQBuAG8AdAAgACQAPwApACAAewAgAEkAZgAgACgARwBlAHQALQBWAGEAcgBpAGEAYgBsAGUAIABMAEEAUwBUAEUAWABJAFQAQwBPAEQARQAgAC0ARQByAHIAbwByAEEAYwB0AGkAbwBuACAAUwBpAGwAZQBuAHQAbAB5AEMAbwBuAHQAaQBuAHUAZQApACAAewAgAGUAeABpAHQAIAAkAEwAQQBTAFQARQBYAEkAVABDAE8ARABFACAAfQAgAEUAbABzAGUAIAB7ACAAZQB4AGkAdAAgADEAIAB9ACAAfQA='
    vsphere: <127.0.0.1> (0, '', '')
    vsphere: <127.0.0.1> PUT /var/folders/c7/8kvczj9j6m5db7jfh2cfmzsh0000gn/T/tmp0JSsUE TO 'win_chocolatey.ps1'
    vsphere: <127.0.0.1> SSH: EXEC sshpass -d57 scp -o ForwardAgent=yes -o StrictHostKeyChecking=no -o Port=54753 -o 'IdentityFile="/private/var/folders/c7/8kvczj9j6m5db7jfh2cfmzsh0000gn/T/ansible-key014387674"' -o User=username -o ConnectTimeout=10 /var/folders/c7/8kvczj9j6m5db7jfh2cfmzsh0000gn/T/tmp0JSsUE '[127.0.0.1]:'"'"''"'"'"'"'"'"'"'"'win_chocolatey.ps1'"'"'"'"'"'"'"'"''"'"''
    vsphere: <127.0.0.1> (0, '', '')
    vsphere: <127.0.0.1> ESTABLISH SSH CONNECTION FOR USER: username
    vsphere: <127.0.0.1> SSH: EXEC sshpass -d57 ssh -o ForwardAgent=yes -o StrictHostKeyChecking=no -o Port=54753 -o 'IdentityFile="/private/var/folders/c7/8kvczj9j6m5db7jfh2cfmzsh0000gn/T/ansible-key014387674"' -o User=username -o ConnectTimeout=10 -tt 127.0.0.1 'PowerShell -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -EncodedCommand UwBlAHQALQBTAHQAcgBpAGMAdABNAG8AZABlACAALQBWAGUAcgBzAGkAbwBuACAATABhAHQAZQBzAHQACgBUAHIAeQAKAHsACgAmACAAJwB3AGkAbgBfAGMAaABvAGMAbwBsAGEAdABlAHkALgBwAHMAMQAnAAoAfQAKAEMAYQB0AGMAaAAKAHsACgAkAF8AbwBiAGoAIAA9ACAAQAB7ACAAZgBhAGkAbABlAGQAIAA9ACAAJAB0AHIAdQBlACAAfQAKAEkAZgAgACgAJABfAC4ARQB4AGMAZQBwAHQAaQBvAG4ALgBHAGUAdABUAHkAcABlACkACgB7AAoAJABfAG8AYgBqAC4AQQBkAGQAKAAnAG0AcwBnACcALAAgACQAXwAuAEUAeABjAGUAcAB0AGkAbwBuAC4ATQBlAHMAcwBhAGcAZQApAAoAfQAKAEUAbABzAGUACgB7AAoAJABfAG8AYgBqAC4AQQBkAGQAKAAnAG0AcwBnACcALAAgACQAXwAuAFQAbwBTAHQAcgBpAG4AZwAoACkAKQAKAH0ACgBJAGYAIAAoACQAXwAuAEkAbgB2AG8AYwBhAHQAaQBvAG4ASQBuAGYAbwAuAFAAbwBzAGkAdABpAG8AbgBNAGUAcwBzAGEAZwBlACkACgB7AAoAJABfAG8AYgBqAC4AQQBkAGQAKAAnAGUAeABjAGUAcAB0AGkAbwBuACcALAAgACQAXwAuAEkAbgB2AG8AYwBhAHQAaQBvAG4ASQBuAGYAbwAuAFAAbwBzAGkAdABpAG8AbgBNAGUAcwBzAGEAZwBlACkACgB9AAoARQBsAHMAZQBJAGYAIAAoACQAXwAuAFMAYwByAGkAcAB0AFMAdABhAGMAawBUAHIAYQBjAGUAKQAKAHsACgAkAF8AbwBiAGoALgBBAGQAZAAoACcAZQB4AGMAZQBwAHQAaQBvAG4AJwAsACAAJABfAC4AUwBjAHIAaQBwAHQAUwB0AGEAYwBrAFQAcgBhAGMAZQApAAoAfQAKAFQAcgB5AAoAewAKACQAXwBvAGIAagAuAEEAZABkACgAJwBlAHIAcgBvAHIAXwByAGUAYwBvAHIAZAAnACwAIAAoACQAXwAgAHwAIABDAG8AbgB2AGUAcgB0AFQAbwAtAEoAcwBvAG4AIAB8ACAAQwBvAG4AdgBlAHIAdABGAHIAbwBtAC0ASgBzAG8AbgApACkACgB9AAoAQwBhAHQAYwBoAAoAewAKAH0ACgBFAGMAaABvACAAJABfAG8AYgBqACAAfAAgAEMAbwBuAHYAZQByAHQAVABvAC0ASgBzAG8AbgAgAC0AQwBvAG0AcAByAGUAcwBzACAALQBEAGUAcAB0AGgAIAA5ADkACgBFAHgAaQB0ACAAMQAKAH0A'
    vsphere: <127.0.0.1> (1, '{"exception":"At line:4 char:3\\r\\n+ \\u0026 \\u0027win_chocolatey.ps1\\u0027\\r\\n+   ~~~~~~~~~~~~~~~~~~~~","msg":"The term \\u0027win_chocolatey.ps1\\u0027 is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.","failed":true}\r\n', '#< CLIXML\r\n<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04"><Obj S="progress" RefId="0"><TN RefId="0"><T>System.Management.Automation.PSCustomObject</T><T>System.Object</T></TN><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="1"><TNRef RefId="0" /><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="2"><TNRef RefId="0" /><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj></Objs>Connection to 127.0.0.1 closed.\r\n')
    vsphere: The full traceback is:
    vsphere: At line:4 char:3

    vsphere: + & 'win_chocolatey.ps1'

    vsphere: +   ~~~~~~~~~~~~~~~~~~~~
    vsphere: failed: [default] (item={u'package_name': u'git'}) => {
    vsphere:     "changed": false, 
    vsphere:     "failed": true, 
    vsphere:     "item": {
    vsphere:         "package_name": "git"
    vsphere:     }, 
    vsphere:     "msg": "The term 'win_chocolatey.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again."
    vsphere: }

And the weird thing, is that it always happens during the win_chocolatey module, through one of the (many) installations, but can vary at which one it fails at.

[SNikalaichyk]

I'm also having the same problem (Packer 1.1.2 with Ansible 2.4.2).
Please find @jborean93's closing comment on ansible/ansible#33087. What do you guys think?

[lawrence-c]

@SNikalaichyk I couldn't get Packer + Ansible working consistently so I implemented jborean93's solution.

More details of the solution can be seen in the google group post: https://groups.google.com/forum/#!starred/packer-tool/AXZSY6UoBNo

[SNikalaichyk]

@surferL, thanks! If my playbooks will continue to fail unexpectedly, I think I'm going to do the same. I still hope for the proper fix though.

[jborean93]

Thanks @SNikalaichyk for pinging me in this. If the maintainers of Packer are reading this feel free to reach out to me as I’m interested in trying to solve this issue and hopefully get Packer working with the native winrm connection plugin of Ansible. Unfortunately I’ve never used Go before so I’ve avoided trying to see what is actually happening in Packer so I could be incorrect with some of my assumptions. I might spend some time soon setting up an environment to try and debug this but any help from some of the experts would be appreciated.

[bhcleek]

@jborean93 I've been following along and would appreciate any help we can get regarding the plugin that packer's ansible-remote module uses.

[SwampDragons]

@jborean93 I'll gladly help you validate any assumptions you have, though we don't as a rule spend much time on the ansible provisioner. It's supported by the community, as we prefer to invest our limited time on things like the shell provisioner (which is Hashicorp-supported), which can also be used to run ansible -- as I believe you've pointed out. But let me know what snags you're hitting and we can try to work through them 🙂

[jborean93]

Sounds good, I just installed Go and downloaded the repo to try and play around with it a bit but will see how I go. Is there a reason why the SSH connector was used historically or is it just something that the community never got round to adding support for other connection plugins?

[SwampDragons]

I'm not totally sure, though I would assume the latter. Here's the original PR and associated conversation for come context: #1969

[bhcleek]

@jborean93 I'm the original author of the ansible provisioner, so I can help answer any questions you have about the tradeoffs made.

Packer only exposes a simple interface, Communicator that can upload files, download files, and execute commands to its plugins. SSH is much simpler than WinRM, and maps pretty well to what Communicator provides. Packer provisioners only communicate with the node using the Communicator interface.

[bhcleek]

@jborean93 also keep in mind that Packer allows one to provision various kinds of images, not all of which corresponds to machines (e.g. docker images); there isn't always a connection that could be used even if Packer exposed its connection to the provisioner. Ansible, on the other hand, assumes that it's talking over a network. So the ansible provisioner sets up an SSH connection for Ansible to talk to, then it translates SSH messages into Packer communicator method calls.

[jborean93]

@bhcleek thanks for the info, much appreciated. So I just have a few more questions for either yourself or @SwampDragons

• Do you have any objections in allowing an override to the SSH server to allow the ansible provisioner to talk directly over the network and not through the SSH connection that is set up
• When the SSH connection receives a command or file, does Packer then talk over WinRM to the Windows host or is it some other form of connection dependent on the builder being used

Unfortunately using this SSH connection to translate commands/files to the Windows host means a lot of the features we have implemented in Ansible for Windows to not work like

• Using become to run processes under an interactive token and then bypassing the restrictions Windows places on a WinRM process
• Async support with Ansible modules to run processes outside of the WinRM job
• Some speed improvements as all commands are run in memory and no files should touch the disk
• I believe the win_reboot (haven't tested) uses some settings unique to the winrm communication plugin that may break with the current implementation

For a high level description of what I am hoping to do

• Keep the current behaviour of using the SSH server that relays commands over the Packer communicator as default
• If the Packer communicator type is winrm, don't set up the SSH server and use the Ansible winrm connection plugin based on the values set in the communicator

This does mean pywinrm must also be installed as it is not included by default with Ansible but that's more a docs update that we would want to handle. Do you see any issues with this approach?

Thanks, hopefully that can get me started and I'm not biting off more than I can chew.

[bhcleek]

@jborean93 That approach has been proposed several times, but is fundamentally incompatible with how Packer works. For background, I'd recommend that you read

• Allow remote ansible provisioner to bypass ssh proxying and simply connect based on sshHostPort state #3846 (comment)
• RFC: Expose generic SSH / WinRM proxies for provisioner #3969
• Feature: allow Ansible provisioner to specify usage of WinRM instead of SSH #3911
• RFQ: Allow provisioner to get communicator details. #3331

It's very easy to recognize how the approach you propose might work to provision a Windows AMI on EC2, but it would be incompatible with building a docker image; Packer fully separates builders from provisioners; provisioners can make no assumption about the underlying communication mechanism.

[jborean93]

Thanks, I'll have a read through those, unfortunately it looks like what I want to do goes against how Packer is designed to work so I don't really see how I could fix this. Even if we were to make it work again with a non pipelining model there is always the chance it could break again in the future as we don't test for it. Plus some of the special features Ansible has like become and async will never work as they are designed for a pipeline like state.

I understand your point about non standard images but TBH I think it is a bit shortsighted to not take advantage of using some of the connection plugins Ansible has when connecting to different platforms like Windows and Docker (full list is here https://docs.ansible.com/ansible/devel/plugins/connection.html#plugin-list).

In the end this isn't my project and I'm just a user so I'm fine with continuing to use shell-local and understand there is a good reason to keep things separate. Although I think the docs should be updated on the Packer site to no longer include the custom connection plugin for WinRM considering it doesn't really work with the latest Ansible versions.

[bhcleek]

I would definitely welcome any improvements to the connection plugin. Ansible's connection plugins have been a moving target, especially as Windows support has matured. I need to sync back up with Ansible and provide some details about what we've had to do to get Ansible to work with the Powershell shell type and an SSH connection. In the meantime, though, any guidance that you can provide to make the connection plugin more stable is very appreciated.

[jborean93]

I'll need to test it out but I'm wondering if modifying the existing custom plugin to support pipelining with Windows will work. I've got a very early stage PR to get Ansible communicating with Windows using the Win32-OpenSSH port here ansible/ansible#33074. This has not been tested to the full extent but it did work for the basics that I tried it with.

I do agree the connection plugin side is a moving target right now, even we are trying to understand how we want to handle using the SSH plugin to work across non POSIX platforms like Windows.

[SNikalaichyk]

So, if I use shell-local to run Ansible, I have to generate temporary host file first. The question is how can I retrieve randomly-generated EC2 Windows password? Is there a variable like "{{ .WinRMPassword }}"?

[SwampDragons]

@SNikalaichyk That seems like a really reasonable ask. I'll see if I can figure out a simple way for you to access it from the template.

[SwampDragons]

@SNikalaichyk is there a reason you aren't willing to just set a static password for winrm in your user_data file?

[SNikalaichyk]

@SwampDragons, we're using monthly AWS Windows AMIs. And in general, embedding passwords is a bad practice.

[SwampDragons]

@SNikalaichyk I lost track of your request because I wasn't tracking it in a separate issue; I've created one #5895

[adarobin]

If using shell-local is the preferred method for dealing with Ansible on Windows, then perhaps #3331 should be reopened?

[ruzickap]

Any update on how to use shell-local with Ansible + WinRM + QEMU/Virtualbox/... to build+configure Windows (orig issue here: #5845)?

In #5845 it was agreed, that using the shell-local is the best way how to use Ansible with Packer, because this provisioner is officially supported by HashiCorp comparing to ansible provisioner which is not.

Actually getting the IP address (needed by Ansible) form the VM which is being build by Packer is not very easy...

Any ideas - how this may be solved?

[SwampDragons]

@SNikalaichyk this patch #6251 should allow you to use the winrm password in shell-local; I've uploaded some builds of the patch on that PR so you can test it if you'd like.

[SNikalaichyk]

@SwampDragons, thanks a lot!
Since Packer version 1.2.2 I've been passing {{ .WinRMPassword }} as an environment variable to the powershell provisioner.

For those interested, my current workflow is:

• powershell provisioner executes custom PowerShell script that creates a temporary Ansible inventory file. This script is needed to retrieve the private IP address of the target EC2 instance
• file provisioner downloads the inventory file
• shell-local provisioner executes ansible-playbook with options

[ruzickap]

@SNikalaichyk - thank you for the short description.
May I ask you to share the powershell script that creates a temporary Ansible inventory file in Windows and example of file provisioner which downloads the Ansible inventory file please?

[zxiiro]

I've run into this issue as well. Using Ansible 2.5.4 the documented way to run packer with Ansible fails. However if I purposely downgrade to Ansible 2.4.0 everything works as expected. Has anyone made any progress with this issue?

Below is my traceback when running the Ansible provisioner.

`
2018/06/26 20:53:11 ui: vexxhost: TASK [Gathering Facts] *********************************************************
2018/06/26 20:53:11 ui: vexxhost: task path: /home/ubuntu/common-packer/provision/windows-builder.yaml:3
vexxhost: task path: /home/ubuntu/common-packer/provision/windows-builder.yaml:3
2018/06/26 20:53:11 ui: vexxhost: Using module file /usr/lib/python2.7/dist-packages/ansible/modules/windows/setup.ps1
vexxhost: Using module file /usr/lib/python2.7/dist-packages/ansible/modules/windows/setup.ps1
vexxhost: <127.0.0.1> ESTABLISH SSH CONNECTION FOR USER: ubuntu
2018/06/26 20:53:11 ui: vexxhost: <127.0.0.1> ESTABLISH SSH CONNECTION FOR USER: ubuntu
vexxhost: The full traceback is:
2018/06/26 20:53:11 ui: vexxhost: The full traceback is:
vexxhost: Traceback (most recent call last):
2018/06/26 20:53:11 ui: vexxhost: Traceback (most recent call last):
vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 138, in run
2018/06/26 20:53:11 ui: vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 138, in run
vexxhost: res = self._execute()
2018/06/26 20:53:11 ui: vexxhost: res = self._execute()
vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 561, in _execute
2018/06/26 20:53:11 ui: vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 561, in _execute
vexxhost: result = self._handler.run(task_vars=variables)
2018/06/26 20:53:11 ui: vexxhost: result = self._handler.run(task_vars=variables)
vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/normal.py", line 46, in run
2018/06/26 20:53:11 ui: vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/normal.py", line 46, in run
vexxhost: result = merge_hash(result, self._execute_module(task_vars=task_vars, wrap_async=wrap_async))
2018/06/26 20:53:11 ui: vexxhost: result = merge_hash(result, self._execute_module(task_vars=task_vars, wrap_async=wrap_async))
vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/init.py", line 720, in _execute_module
2018/06/26 20:53:11 ui: vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/init.py", line 720, in _execute_module
vexxhost: self._make_tmp_path()
2018/06/26 20:53:11 ui: vexxhost: self._make_tmp_path()
vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/init.py", line 257, in _make_tmp_path
2018/06/26 20:53:11 ui: vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/init.py", line 257, in _make_tmp_path
vexxhost: result = self._low_level_execute_command(cmd, sudoable=False)
2018/06/26 20:53:11 ui: vexxhost: result = self._low_level_execute_command(cmd, sudoable=False)
vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/init.py", line 917, in _low_level_execute_command
2018/06/26 20:53:11 ui: vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/init.py", line 917, in _low_level_execute_command
2018/06/26 20:53:11 ui: vexxhost: rc, stdout, stderr = self._connection.exec_command(cmd, in_data=in_data, sudoable=sudoable)
vexxhost: rc, stdout, stderr = self._connection.exec_command(cmd, in_data=in_data, sudoable=sudoable)
2018/06/26 20:53:11 ui: vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/connection/ssh.py", line 976, in exec_command
vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/connection/ssh.py", line 976, in exec_command
vexxhost: use_tty = self.get_option('use_tty')
2018/06/26 20:53:11 ui: vexxhost: use_tty = self.get_option('use_tty')
vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/init.py", line 58, in get_option
2018/06/26 20:53:11 ui: vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/plugins/init.py", line 58, in get_option
vexxhost: option_value = C.config.get_config_value(option, plugin_type=get_plugin_class(self), plugin_name=self._load_name, variables=hostvars)
2018/06/26 20:53:11 ui: vexxhost: option_value = C.config.get_config_value(option, plugin_type=get_plugin_class(self), plugin_name=self._load_name, variables=hostvars)
2018/06/26 20:53:11 ui: vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/config/manager.py", line 284, in get_config_value
vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/config/manager.py", line 284, in get_config_value
2018/06/26 20:53:11 ui: vexxhost: value, _drop = self.get_config_value_and_origin(config, cfile=cfile, plugin_type=plugin_type, plugin_name=plugin_name, keys=keys, variables=variables)
vexxhost: value, _drop = self.get_config_value_and_origin(config, cfile=cfile, plugin_type=plugin_type, plugin_name=plugin_name, keys=keys, variables=variables)
2018/06/26 20:53:11 ui: vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/config/manager.py", line 303, in get_config_value_and_origin
vexxhost: File "/usr/lib/python2.7/dist-packages/ansible/config/manager.py", line 303, in get_config_value_and_origin
vexxhost: defs = self._plugins[plugin_type][plugin_name]
2018/06/26 20:53:11 ui: vexxhost: defs = self._plugins[plugin_type][plugin_name]
2018/06/26 20:53:11 ui: vexxhost: KeyError: 'connection'
vexxhost: KeyError: 'connection'
vexxhost: fatal: [default]: FAILED! => {
2018/06/26 20:53:11 ui: vexxhost: fatal: [default]: FAILED! => {
vexxhost: "msg": "Unexpected failure during module execution.",
2018/06/26 20:53:11 ui: vexxhost: "msg": "Unexpected failure during module execution.",
2018/06/26 20:53:11 ui: vexxhost: "stdout": ""
vexxhost: "stdout": ""
2018/06/26 20:53:11 ui: vexxhost: }
vexxhost: }
vexxhost: to retry, use: --limit @/home/ubuntu/common-packer/provision/windows-builder.retry
2018/06/26 20:53:11 ui: vexxhost: to retry, use: --limit @/home/ubuntu/common-packer/provision/windows-builder.retry
vexxhost:
2018/06/26 20:53:11 ui: vexxhost:

`

[adarobin]

@zxiiro I posted a gist in #5845 which resolved the issue for me.

I ended up just calling ansible with the shell-local provisioner as there are still a few other quirks even with the above fix. I can share my code that generates a host file for ansible if it would be useful.

[zxiiro]

@adarobin Please do share your working example with shell-local that would help me a lot. Thanks.

[adarobin]

Here are the provisioners I am using to generate a host file for use with ansible called with the shell-local provisioner:

{
  "type": "powershell",
  "inline": [
    "switch -Wildcard ($env:PACKER_BUILDER_TYPE) {",
    "  \"amazon*\" { $publicipv4 = Invoke-RestMethod -Method GET -Uri http://169.254.169.254/latest/meta-data/public-ipv4 }",
    "  \"azure*\" { $publicipv4 = Invoke-RestMethod -Method GET -Uri \"http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-12-01&format=text\" -Headers @{\"Metadata\" = \"true\"} }",
    "  \"googlecompute\" { $publicipv4 = Invoke-RestMethod -Method GET -Uri http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip -Headers @{\"Metadata-Flavor\" = \"Google\"} }",
    "  Default { Throw \"Unknown PACKER_BUILDER_TYPE\" } }",
    "\"[{{build_name}}]\" > C:\\Windows\\Temp\\host",
    "$publicipv4 >> C:\\Windows\\Temp\\host"
    ]
},
{
  "type": "file",
  "direction": "download",
  "source": "C:\\Windows\\Temp\\host",
  "destination": "playbook/{{build_name}}-host"
},
{
  "type": "shell-local",
  "inline": [
    "export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES",
    "case \"$PACKER_BUILDER_TYPE\" in",
    "  amazon*) ANSIBLE_USER={{user `aws_winrm_user`}};;",
    "  azure*) ANSIBLE_USER={{user `azure_winrm_user`}};;",
    "  googlecompute) ANSIBLE_USER={{user `gcp_winrm_user`}};;",
    "esac",
    "dos2unix playbook/{{build_name}}-host",
    "ansible-playbook -v -i playbook/{{build_name}}-host --extra-vars \"ansible_user=$ANSIBLE_USER ansible_password={{.WinRMPassword}} ansible_become_pass={{.WinRMPassword}} ansible_port=5986 ansible_connection=winrm ansible_winrm_server_cert_validation=ignore ansible_winrm_transport=ntlm\" playbook/main.yml"
  ]
}

That "export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES" junk is an Ansible workaround for macOS. If you are on Linux you won't need it. One of my colleagues figured out a way to eliminate the dos2unix step as well. I'll edit this post if I can find that code.

Edit: This gist should eliminate the dox2unix step though I have not tested it yet myself.

[ruzickap]

If you are interested in building windows using packer+ansible with shell-local provisioner used with libvirt / virtualbox you can check this example:
https://github.com/ruzickap/packer-templates/blob/78ef8fcaf556b214d434f9e25e465081c023cbab/windows.json#L130-L132

[Wenzel]

Thanks for the trick @ruzickap !

Anyone got an update on this issue ?
I tried to use the Ansible provisioner today with Ansible 2.6.0 and it appears it's still broken: #6438

[adarobin]

@Wenzel I updated my gist for the Ansible connection plugin for Packer to work with Ansible 2.6.

I used code from master and it has references to 2.7 but they don't seem to cause any issue running with 2.6.

[Wenzel]

@adarobin , I don't understand because I have the same connection_plugin as you, except for the documentation part: https://github.com/Wenzel/bug_packer_ansible/blob/master/ansible/connection_plugins/packer.py

And I still get errors on 2.6.0.

Any clue ? 🤔

[adarobin]

@Wenzel The DOCUMENTATION string is required with Ansible 2.4.x and newer.

Edit: Documented here

[jborean93]

Yes you need the documentation part. It is used by Ansible to determine what options are available to the connection plugin. It’s more than just documentation, it is self documenting code.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.