hostvars['127.0.0.1']['ansible_system'] may not exist

[dmitry-kulikov]

Expected behavior:

Installation completed without errors.

Actual Behavior:

Installation completed with minor errors:

TASK [streisand-gateway : Attempt to open the instructions on Linux (if applicable). Errors in this task are ignored because the `xdg-open` command is not always available.] ***
fatal: [x.x.x.x]: FAILED! => {"failed": true, "msg": "The conditional check 'hostvars['127.0.0.1']['ansible_system'] == \"Linux\"' failed. The error was: error while evaluating conditional (hostvars['127.0.0.1']['ansible_system'] == \"Linux\"): 'dict object' has no attribute 'ansible_system'\n\nThe error appears to have been in '/media/veracrypt1/streisand/playbooks/roles/streisand-gateway/tasks/main.yml': line 199, column 9, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n      - name: Attempt to open the instructions on Linux (if applicable). Errors in this task are ignored because the `xdg-open` command is not always available.\n        ^ here\n"}

Steps to Reproduce:

Run ./streisand.

Additional Details:

Really minor issue. I guess it should be fixed by replacing of

playbooks/roles/streisand-gateway/tasks/main.yml:202
- when: hostvars['127.0.0.1']['ansible_system'] == "Linux"
+ when: hostvars['127.0.0.1']['ansible_system'] is defined and hostvars['127.0.0.1']['ansible_system'] == "Linux"

and

playbooks/roles/streisand-gateway/tasks/main.yml:207
- when: hostvars['127.0.0.1']['ansible_system'] == "Darwin"
+ when: hostvars['127.0.0.1']['ansible_system'] is defined and hostvars['127.0.0.1']['ansible_system'] == "Darwin"

Target Cloud Provider: Scaleway

Operating System of target host: Ubuntu 16.04

Operating System of client: Ubuntu 14.04

Version of Ansible, using ansible --version : 2.3.1.0

[cpu]

Hi @dmitry-kulikov,

I believe I've seen this error on my local machine as well and had meant to make a note to fix it. Thanks for reporting! It obviously slipped my mind 😆

I'd like to look into this a little bit deeper but won't have the time immediately. I'll try to have a fix posted in the next day or two. It should be safe to ignore this error in the mean time, you will just have to open the generated documentation yourself manually (which was probably already true if you are doing a localhost install on a remote server).

Thanks again!

[cpu]

I was able to reproduce this on Archlinux with Ansible 2.3.1.0.

Really minor issue. I guess it should be fixed by replacing of
playbooks/roles/streisand-gateway/tasks/main.yml:202

• when: hostvars['127.0.0.1']['ansible_system'] == "Linux"

• when: hostvars['127.0.0.1']['ansible_system'] is defined and hostvars['127.0.0.1']['ansible_system'] == "Linux"

I think this will patch around the error but it won't result in Linux clients having the docs opened. I'd rather find a better solution if possible.

On my system I notice that there is no hostvars['127.0.0.1'] but there is a hostvars['localhost'] that has the correct ansible_system key. I suspect using hostvars['127.0.0.1'] will fix it for us but I'm nervous other systems will have the inverse problem (127.0.0.1 but no localhost).

[cpu]

On my system I notice that there is no hostvars['127.0.0.1'] but there is a hostvars['localhost'] that has the correct ansible_system key. I suspect using hostvars['127.0.0.1'] will fix it for us but I'm nervous other systems will have the inverse problem (127.0.0.1 but no localhost).

Update: using "localhost" didn't help. I'm a bit stumped. It seems hostvars largely "pretends" to be a dict and there might be something else at work here. I'll have to revisit. Out of time for the night.

[cpu]

I figured out the root cause of this bug while working on something separate. Serendipity!

The tl;dr is that the existing server flow never ended up running a gather_facts: true for localhost to populate hostvars.

I've fixed it as part of cpu@134e00a - I haven't opened a PR for this commit yet since it builds on top of #936 but I expect I will be able to merge it in the next week or so.

[cpu]

Should be all fixed in master by way of #970.