Packer: ansible-local extra_arguments passing extra-vars in amazon-chroot doesn't work

[tjbaker]

cross ref comment https://github.com/hashicorp/packer/issues/5335#issuecomment-405023876

Ansible >=v1.2.1 does not work for me with amazon-chroot and ansible-local and extra_arguments passing extra-vars.

All the following incantations do not appear to actually provide the extra-var in scope to Ansible. A simple debug trying to print the variable results in VARIABLE IS NOT DEFINED!

The following all work <= 1.2.0 and fail >= 1.2.1 . I've tried all the way up to 1.2.4 and all fail.

"extra_arguments": [ "--extra-vars", "\"application={{user `application`}}\""]
"extra_arguments": [ "--extra-vars", "application={{user `application`}}"]
"extra_arguments": [ "--extra-vars application={{user `application`}}"]
"extra_arguments": [ "--extra-vars \"application={{user `application`}}\""]

In all cases the Executing Ansible: command printed to stdout look visually correct, yet the variable is not actually defined when referenced. Running the command printed to the screen manually works as expected.

I've tried with Ansible 2.2.1.0 and 2.6.1 in the chroot, no difference.

sample output @ 1.2.1

amazon-chroot: Executing Ansible: cd /tmp/packer-provisioner-ansible-local/5b49f87a-c08b-65c4-ca65-4cbcfcb6a385 && /usr/local/bin/ansible-playbook -i foo, /tmp/packer-provisioner-ansible-local/5b49f87a-c08b-65c4-ca65-4cbcfcb6a385/post-pack.yml --extra-vars "packer_build_name=amazon-chroot packer_builder_type=amazon-chroot packer_http_addr=" --extra-vars "application=base" -c local -i /tmp/packer-provisioner-ansible-local/5b49f87a-c08b-65c4-ca65-4cbcfcb6a385/packer-provisioner-ansible-local799069697
    amazon-chroot:
    amazon-chroot: PLAY [localhost] ***************************************************************
    amazon-chroot:
    amazon-chroot: TASK [debug] *******************************************************************
    amazon-chroot: ok: [localhost] => {
    amazon-chroot:     "application": "VARIABLE IS NOT DEFINED!"
    amazon-chroot: }

When I run with 1.2.0 it works as expected.

amazon-chroot: Executing Ansible: cd /tmp/packer-provisioner-ansible-local/5b49fd84-5039-f7e4-2115-75bcd16914b4 && /usr/local/bin/ansible-playbook -i foo, /tmp/packer-provisioner-ansible-local/5b49fd84-5039-f7e4-2115-75bcd16914b4/post-pack.yml --extra-vars \"packer_build_name=amazon-chroot packer_builder_type=amazon-chroot packer_http_addr=\" --extra-vars application=base --extra-vars envname=staging -c local -i /tmp/packer-provisioner-ansible-local/5b49fd84-5039-f7e4-2115-75bcd16914b4/packer-provisioner-ansible-local221737869
    amazon-chroot:
    amazon-chroot: PLAY [localhost] ***************************************************************
    amazon-chroot:
    amazon-chroot: TASK [debug] *******************************************************************
    amazon-chroot: ok: [127.0.0.1] => {
    amazon-chroot:     "application": "base"
    amazon-chroot: }

[rickard-von-essen]

There is only one commit between v1.2.0 and v1.2.1 touching ansible-local, 7d9a86becb0d4790ce4cd10ecd6eb7c3f059db89 which definitely looks like the cause of this. Good triaging! 🎯

[rickard-von-essen]

Introduced in #5888, (which is a revert of another PR!?)

[rickard-von-essen]

A counter example with the docker builder where this seems to work correctly:

{
  "variables": {
    "app": "testing"
  },
  "builders": [
    {
      "type": "docker",
      "pull": "true",
      "image": "alpine",
      "run_command": [ "-d", "-t", "-i", "{{.Image}}", "/bin/ash"],
      "commit": true
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "inline": [
        "apk add ansible"
      ]
    },
    {
      "type": "ansible-local",
      "playbook_file": "local.yml",
      "extra_arguments": [ "-vvv", "--extra-vars \"app={{ user `app` }} ansible_python_interpreter=/usr/bin/python3\"" ]
    }
  ]
}

---

- hosts: all
  tasks:
    - debug:
        var: app

$ packer build alpine_ansible.json  
[...]
    docker: Executing Ansible: cd /tmp/packer-provisioner-ansible-local/5b4ce58b-008a-0425-dd66-09889e34d5cc && ANSIBLE_FORCE_COLOR=1 PYTHONUNBUFFERED=1 ansible-playbook /tmp/packer-provisioner-ansible-local/5b4ce58b-008a-0425-dd66-09889e34d5cc/local.yml --extra-vars "packer_build_name=docker packer_builder_type=docker packer_http_addr=" -vvv --extra-vars "app=testing ansible_python_interpreter=/usr/bin/python3" -c local -i /tmp/packer-provisioner-ansible-local/5b4ce58b-008a-0425-dd66-09889e34d5cc/packer-provisioner-ansible-local108649738
[...]
    docker: ok: [127.0.0.1] => {
    docker:     "app": "testing"
    docker: }
[...]

[SwampDragons]

Definitely time to sit down and fix this escaping Once And For All.

[tamsky]

Oh man - I just burned a few hours on this exact scenario

I found both

• https://github.com/hashicorp/packer/issues/5885
• https://github.com/hashicorp/packer/issues/6400
  and even the "original" feature/issue
• https://github.com/hashicorp/packer/issues/555

I triaged using docker like @tjbaker...
and only after that, did I find this bug.

In all cases the Executing Ansible: command printed to stdout look visually correct, yet the variable is not actually defined when referenced. Running the command printed to the screen manually works as expected.

here here. same here.

I thought I was going crazy -- especially since the "executing ansible" output looked correct.
--extra-vars "packer_build_name=docker packer_builder_type=docker packer_http_addr="

[SwampDragons]

:( sorry to hear it! I'll try make some time to sit down with this next week.

[tamsky]

Thanks, but not a big deal afaict. =)
For now, I think we all can work around the issue by manually populating extra_arguments:

provisioners:
- type: ansible-local
  playbook_file: ...
  extra_arguments: "--extra-vars whatever_vars_are_required=value"

Also, by triaging it myself, I learned the speed and joy of the docker builder,
which I'd never used before.

[SwampDragons]

I think I finally found root cause here, at least for the ansible + chroot combo; it wasn't in the ansible builder. It was in the chroot communicator. If this sounds like it applies to you, you can check out the PR linked above (I'll attach a linux build to it) or you can wait for the next release.

[tamsky]

Thank you @SwampDragons !

[hashibot[bot]]

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.