Undefined attributes in dict

[Migsi]

Describe the bug

To begin with, I'm unsure if this is a bug or just happens because I'm doing it wrong.

When trying to provision a remote Ubuntu LXC on a Proxmox Host, the role immediately fails with the error fatal: [my.remote.host -> localhost]: FAILED! => {"msg": "'dict object' has no attribute 'password'"}

Playbook

I just paste the part of the playbook relating to locale(s), which is within our "common" role, as setting the locale is one of the things that needs to be done on all of our hosts.

...
  # Locale role
- name: Change locale using external role
  include_role:
    name: robertdebock.locale
...

Our config done via group_vars/all.yml:

...
# Default locale configuration
locale_lang: en_GB.UTF-8
locale_timezone: Europe/Vienna
...

Our requirements.yml which is fed into ansible before every run:

roles:
  - name: robertdebock.bootstrap
    version: 5.2.3

  - name: robertdebock.locale
    version: 3.1.0
...
collections:
...

Output

The first "TASK" in the output is the line calling the role, as described above.

...
TASK [Change locale using external role] **************************************************************************************************************************************************************************

TASK [robertdebock.locale : test if locale_lang is set correctly] *************************************************************************************************************************************************
fatal: [my.remote.host -> localhost]: FAILED! => {"msg": "'dict object' has no attribute 'password'"}
...

Environment

• Control node OS: NAME="Ubuntu" VERSION="20.04.3 LTS (Focal Fossa)"
• Control node Ansible version: ansible [core 2.11.3]
• Managed node OS: NAME="Ubuntu" VERSION="18.04.5 LTS (Bionic Beaver)" actually just a LXC on a Proxmox 6.4-13 Host (Debian 10)

[robertdebock]

I think it has to do with your setup; the password attribute is not related to this role.

The error you are seeing comes from this code:

- name: test if locale_lang is set correctly
  ansible.builtin.assert:
    that:
      - locale_lang is defined
      - locale_lang is string
    quiet: yes

Maybe just to be sure you can quote your values:

locale_lang: "en_GB.UTF-8"
locale_timezone: "Europe/Vienna"

Although I don't really expect that to cause an issue.

Hope you find the issue, please reopen if you need further help.

[Migsi]

Maybe just to be sure you can quote your values:

locale_lang: "en_GB.UTF-8"
locale_timezone: "Europe/Vienna"

Although I don't really expect that to cause an issue.

You were right about that not causing the issue.

I think it has to do with your setup; the password attribute is not related to this role.

I can't imagine what is causing the assertion to fail. No other role/task is messing with locales, and I checked the host, they are all set properly (to "C", no clue why, but its fine, its the initial state that should get changed by this role).
Regarding the misterious password attribute, I can't find any hints on where it comes from. We don't use assertions ourself. Anyway it wouldn't make a lot of sense if your assertion is triggered by a previous handled one (that looked for password somewhere), though I can't say for sure there exists a bug within ansible itself?

If you don't mind, I'd ask you to reopen the issue as I still don't have a fix.

[robertdebock]

What a strange error, I'm actually curious where it comes from.

Can you run the playbook with a couple of '-vvv's?

[Migsi]

Sorry for my late response, I didn't have time to retry this earlier. I ran the play using -vvvvvv (should be one more than max verbosity?) but the (above posted) output stayed the same. Allthough, the role call itself outputted some more, but I guess useless information.

TASK [Change locale using external role] **************************************************************************************************************************************************************************
task path: /path/to/ansible/provisioning/roles/common/tasks/main.yml:76
Read vars_file 'vars/common.yml'
Read vars_file 'vars/authorized_keys.yml'
Read vars_file 'vars/gpg_keys.yml'
Read vars_file 'vars/common.yml'
Read vars_file 'vars/authorized_keys.yml'
Read vars_file 'vars/gpg_keys.yml'
Read vars_file 'vars/common.yml'
Read vars_file 'vars/authorized_keys.yml'
Read vars_file 'vars/gpg_keys.yml'
Read vars_file 'vars/common.yml'
Read vars_file 'vars/authorized_keys.yml'
Read vars_file 'vars/gpg_keys.yml'
Read vars_file 'vars/common.yml'
Read vars_file 'vars/authorized_keys.yml'
Read vars_file 'vars/gpg_keys.yml'
statically imported: /path/to/.ansible/roles/robertdebock.locale/tasks/assert.yml
Read vars_file 'vars/common.yml'
Read vars_file 'vars/authorized_keys.yml'
Read vars_file 'vars/gpg_keys.yml'
Read vars_file 'vars/common.yml'
Read vars_file 'vars/authorized_keys.yml'
Read vars_file 'vars/gpg_keys.yml'
Read vars_file 'vars/common.yml'
Read vars_file 'vars/authorized_keys.yml'
Read vars_file 'vars/gpg_keys.yml'
Read vars_file 'vars/common.yml'
Read vars_file 'vars/authorized_keys.yml'
Read vars_file 'vars/gpg_keys.yml'

TASK [robertdebock.locale : test if locale_lang is set correctly] *************************************************************************************************************************************************
task path: /path/to/.ansible/roles/robertdebock.locale/tasks/assert.yml:3
fatal: [my.remote.host -> localhost]: FAILED! => {
    "msg": "'dict object' has no attribute 'password'"
}

NO MORE HOSTS LEFT ************************************************************************************************************************************************************************************************

[Migsi]

I'm suspecting the issue is triggered by some sort of underlying ansible bug. I managed to reproduce the exact same issue on a different play, using partially the same vars as in the play I mentioned above. Appearently the unrelated var password is not properly populated during this play. I still didn't manage to understand exactly why, but I'll look into it. In the meantime I was able to circumvent it by reducing the inventory to those hosts I'm intrested in at play time and disabling error_on_undefined_vars in ansible config.

I didn't try yet if the mentioned workaround allows me to use your role again, I'll test it ASAP and close the issue if I succeed.

[Migsi]

I managed to sort out the issue regarding the unrelated var password and thus was able to run the locale role again. It was all my fault messing up variables. Anyway it is not clear, why your role initially triggered the behavior, especially as in the play where it is used all those vars must be populated for the rest to work (which it does). This suggests there are some issues with var handling within Ansible itself, I might open a bug report at their repo. Problem solved, yay! At least i thought so...
Unfortunately I encountered a new issue after the play went through. As that issue is unrelated, I'll open a new issue report for it.

[robertdebock]

Good to hear your issue is "fixes", indeed please make issues for any problem you spot, it helps me and all other users of these roles. Thanks!