Do we still need core__distribution and core__distribution_release?

[imrejonk]

According to the documentation, the variables core__distribution and core__distribution_release exist because Ansible fails to autodetect this information on some distributions. The values are placed in local facts and are used by other roles.

I see three problems with this:

1. The values in /etc/ansible/facts.d/core.fact need manual updating after a distribution upgrade. The administrator must remember to do this before running any role which depends on these facts.
2. The documentation does not say how or why Ansible fails to autodetect this information, nor is there a link to an Ansible bug report.
3. This Ansible bug could have been solved already, which would make this workaround obsolete.

I've never experienced Ansible wrongly detecting my OS distribution, but maybe this is still an issue for some users out there (in which case we should update the documentation). If not, we should consider removing these variables.

[drybjed]

The issue was present in Raspbian which was identified by Ansible as Debian. This could be averted by using the ansible_lsb.codename Ansible fact when the lsb-release Debian package was installed on the host. Since ansible_lsb.release and ansible_distribution_release are different facts, to avoid having to replace the release check in all roles, I put that in the core role and provided as a fact to other roles. But yeah, upgrading the OS on the host puts a wrench in this.

I don't remember any other OS besides Raspbian being misidentified by Ansible in this way, so it would be interesting to check if that's still the case - any Raspbian users around to confirm it? I wonder if @hleitzell is still around...

I agree that the best course of action would be to stick to facts provided by Ansible itself. I don't remember any time I had to override _distribution or _distribution_release globally via the core role, so this could be dropped entirely. An alternative would be to not go through role defaults and provide the actual information in the fact script itself, by interrogating the lsb_release information as needed - in this case, the actual release would be correct, even after the OS was upgraded. That way we can still use ansible_local.core.distribution_release as the final source of truth, avoiding checking two Ansible facts.

[imrejonk]

I have a few Pi's laying around, I'll see if I can reproduce it with the latest Raspbian.

[imrejonk]

Raspbian is apparently now called Raspberry Pi OS (see https://www.raspberrypi.com/software/). It is still called Raspbian in /etc/os-release and other places.

Raspberry Pi OS Buster on 32-bit ARM (armhf) has this:

pi@raspberrypi:~ $ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

"ansible_distribution": "Debian",
"ansible_distribution_file_parsed": true,
"ansible_distribution_file_path": "/etc/os-release",
"ansible_distribution_file_variety": "Debian",
"ansible_distribution_major_version": "10",
"ansible_distribution_release": "buster",
"ansible_distribution_version": "10",
"ansible_lsb": {
    "codename": "buster",
    "description": "Raspbian GNU/Linux 10 (buster)",
    "id": "Raspbian",
    "major_release": "10",
    "release": "10"
},

Raspberry Pi OS Bullseye on 32-bit ARM (armhf):

pi@raspberrypi:~ $ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

"ansible_distribution": "Debian",
"ansible_distribution_file_parsed": true,
"ansible_distribution_file_path": "/etc/os-release",
"ansible_distribution_file_variety": "Debian",
"ansible_distribution_major_version": "11",
"ansible_distribution_release": "bullseye",
"ansible_distribution_version": "11",
"ansible_lsb": {
    "codename": "bullseye",
    "description": "Raspbian GNU/Linux 11 (bullseye)",
    "id": "Raspbian",
    "major_release": "11",
    "release": "11"
},

And Raspberry Pi OS Bullseye on 64-bit ARM (arm64):

pi@raspberrypi:~ $ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

"ansible_distribution": "Debian",
"ansible_distribution_file_parsed": true,
"ansible_distribution_file_path": "/etc/os-release",
"ansible_distribution_file_variety": "Debian",
"ansible_distribution_major_version": "11",
"ansible_distribution_release": "bullseye",
"ansible_distribution_version": "11",
"ansible_lsb": {
    "codename": "bullseye",
    "description": "Debian GNU/Linux 11 (bullseye)",
    "id": "Debian",
    "major_release": "11",
    "release": "11"
},

I am not familiar with the intricacies of the ansible_distribution fact, but it looks like it indeed fails to identify the Raspberry Pi OS distribution on 32-bit ARM (an unofficial Debian armhf port). ansible_lsb.id still handles this correctly. ansible_distribution_release works fine because Raspberry Pi OS uses the same codenames as Debian.

Raspberry Pi OS Bullseye on 64-bit ARM is really just the official arm64 port of Debian Bullseye with an additional package repository. The sources.list file even contains the regular Debian APT sources.

Anyway, it looks like a local fact for setting the distribution (and maybe also codename) is still useful. There are still two problems to solve:

1. The documentation of the core__distribution and core__distribution_release variables could use a bit of background information, which can be done by simply linking to this issue.
2. The current setup still requires manual intervention for distribution upgrades. The cause of this can be found in the common playbook: the Prepare APT configuration on a host play runs before the core playbook gets imported, resulting in the apt role configuring the sources.list file with outdated information. We can't just order the core playbook import before the Prepare APT configuration on a host play, because some tasks in the core role expect the APT configuration to be set. It's a catch-22. I think the only way to solve this would be to change the apt role defaults like so:

apt__distribution: '{{ ansible_lsb.id|d(ansible_distribution) }}'
apt__distribution_release: '{{ ansible_lsb.codename|d(ansible_distribution_release) }}'

This should result in expected behavior on both Debian and Raspberry Pi OS, and doesn't hinder distribution upgrades. People who run other Debian-based distributions that are not correctly auto-detected will just have to override these two default variables.