0.3.1 throws error

[MarcusCaepio]

Hi all,
after upgrade from 0.3.0 to 0.3.1 the collection throws an error:

{
"The task includes an option with an undefined variable. 
The error was: 
{
 'files': 
  [
   '{{ ansible_os_family }}-{{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml', 
   '{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml', 
   '{{ ansible_os_family }}-{{ ansible_distribution }}.yml', 
   '{{ ansible_os_family }}-{{ ansible_lsb.id }}.yml', 
   '{{ ansible_os_family }}.yml', 
   'default.yml'
   ], 
  'paths': 
  ['{{ role_path }}/vars']}: 'dict object' has no attribute 'id'. 'dict object' has no attribute 'id'. 
  {
  'files': 
  [
  '{{ ansible_os_family }}-{{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml', 
  '{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml', 
  '{{ ansible_os_family }}-{{ ansible_distribution }}.yml', 
  '{{ ansible_os_family }}-{{ ansible_lsb.id }}.yml', 
  '{{ ansible_os_family }}.yml', 'default.yml'
  ], 
  'paths': [
  '{{ role_path }}/vars']}: 'dict object' has no attribute 'id'. 'dict object' has no attribute 'id'
  The error appears to be in '/xxx/xxx/.ansible/collections/ansible_collections/icinga/icinga/roles/repos/tasks/main.yml': line 2, column 3, but may
  be elsewhere in the file depending on the exact syntax problem.
  The offending line appears to be:
  name: Include OS specific vars\n  ^ here\n"
}

Rollbacked to 0.3.0 and everything is working fine again.
Maybe one have a look?

Cheers,
Marcus

[mocdaniel]

This is most likely due to the ansible_lsb dict not being populated. Do you have lsb core or similar installed on your machine?

What does ansible -m setup show for the hosts in question?

[MarcusCaepio]

Indeed, ansible_lsb is empty on my hosts.
But then we are not talking about a patch with the version number 0.3.1 for the last release, but about a major release with an additional, undocumented breaking change and dependency of the lsb_release package, right? Can't you just use the facts from ansible_distribution, which are already present?

[martialblog]

I think the change came in here #203 and we didn't anticipate what that would change

[mocdaniel]

I sure think so. I don't know the reasoning of introducing the check for more environment information, let's wait for additional information from @mkayontour. The changes were introduced in #203.

[stdevel]

Same issue here on AlmaLinux 9.3, x86_64. Collection version 0.3.0 works without any issues.

[mocdaniel]

As I don't have access to a Raspberry Pi right now and won't have until next week, maybe @gianmarco-mameli could provide some context as to why they chose to implement the OS detection for Raspbian via ansible_lsb.id and if there might be a different way to do this.

[gianmarco-mameli]

Hi, the ansible_lsb.id is the only fact that contain the string 'Raspbian' (and also the description), and it's effective only on armhf architecture, the arm64 version of raspbian os is populated with 'Debian'.
This are the outputs from various Debians at home, unfortunately at this time I don't have access to other distributions

arm64 Debian Bookworm

❯ ansible -m setup harbor -a 'filter=ansible_lsb,ansible_distribution'   
harbor | SUCCESS => {
    "ansible_facts": {
        "ansible_distribution": "Debian",
        "ansible_lsb": {
            "codename": "bookworm",
            "description": "Debian GNU/Linux 12 (bookworm)",
            "id": "Debian",
            "major_release": "12",
            "release": "12"
        },
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false
}

arm64 Raspbian OS

❯ ansible -m setup rpitest2 -a 'filter=ansible_lsb,ansible_distribution' 
rpitest2 | SUCCESS => {
    "ansible_facts": {
        "ansible_distribution": "Debian",
        "ansible_lsb": {
            "codename": "bookworm",
            "description": "Debian GNU/Linux 12 (bookworm)",
            "id": "Debian",
            "major_release": "12",
            "release": "12"
        }
    },
    "changed": false
}

armhf Rasbpian OS

❯ ansible -m setup rpi-node1 -a 'filter=ansible_lsb,ansible_distribution'
rpi-node1 | SUCCESS => {
    "ansible_facts": {
        "ansible_distribution": "Debian",
        "ansible_lsb": {
            "codename": "bullseye",
            "description": "Raspbian GNU/Linux 11 (bullseye)",
            "id": "Raspbian",
            "major_release": "11",
            "release": "11"
        }
    },
    "changed": false
}

So in this case the fastest solution is to modify the previous line that raises the error, because I think that ansible_lsb.id, when defined, is always the same as ansible_distribution, maybe if you have other distribution to test is appreciated

adapt this line
- "{{ ansible_os_family }}-{{ ansible_lsb.id if ansible_lsb.id is defined else ansible_distribution }}.yml"

remove this line that raise the error
- "{{ ansible_os_family }}-{{ ansible_lsb.id }}.yml"

Gianmarco

[mkayontour]

@gianmarco-mameli I would adapt your solution. After all I would not expect everyone to install lsb.
And always if there's a variable which could be missing then "is defined" needs to be there.

[gianmarco-mameli]

HI @mkayontour, seems perfect, thank you

[mocdaniel]

This will be fixed in the upcoming release v0.3.2