Debian bullsye image Ansible detection

[Ian Wienand]

Hello,

In short, Ansible reports "n/a" for ansible_distribution_release on
our new bullseye nodes.  This screws up our mirror setup.  This has
turned into quite an adventure.

Currently, Debian is frozen to create the "bullseye" release.  This
means that "bullseye" is really an alias for "testing", that will turn
into the release after the freeze period.

So currently Debian bullseye reports itself in /etc/debian_version or
/etc/os-release as "bullseye/sid".  This sort of makes sense if you
consider that you don't commit things to "testing" directly, they go
into unstable ("sid") and then migrate after a period of stability.
So you can't have "base-files" package in bullseye that hasn't gone
through unstable/sid.  You can read "bullseye/sid" as "we've chosen
the name bullseye and packages going through unstable are destined for
it".

Now, you might see a problem in that "unstable" and "bullseye"
(testing) now both report themselves in these version files as the
same thing (because the unstable packages that provide them move into
testing).

"lsb_release -c" tries to be a bit smart about this, and looks at the
output of "apt-cache policy" to try and see if you are actually
pulling the .deb files from a bullseye repo or an unstable one.

Interestingly, this relies on a "Label" being present in the mirror
release files.  Since we use reprepro to build our own mirrors, we do
not have this (and why nobody else who doens't use our mirrors seems
to notice this problem).  A fix is proposed with

 https://review.opendev.org/c/opendev/system-config/+/787661

So "lsb_release -c" doesn't report anything, leaving Ansible in the
dark as to what repo it uses.

When "lsb_release -c" doesn't return anything helpful, Ansible tries
to do it's own parsing of the release files.  I started hacking on
these, but the point raised in

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845651

gave me pause.  It is a fair point that you can not really know if
you're on bullseye or sid by examining these files.  N/A is probably
actually the correct answer from Ansible's POV.  Anyway, that is

 https://github.com/ianw/ansible/commit/847817a82ed86b5f39a4ccc3ffbff0e0cd63e8cc

Now, even more annoyingly, setting the label in our mirrors may not be
sufficient for "lsb_release -c" to work on our images, because we have
cleared out the apt repositories.  You would need to run "apt-get
update" before Ansible tries to run "lsb_release" to populate it's
facts.  Now the problem is that we're trying to use Ansible's fact
about the distro name to setup apt to point to our mirrors -- so we
can't apt-get update before we have that written out!  Classic chicken
and egg.

The only other idea I have is to hack dib/early setup overwrite
/etc/debian_version with "11.0" so that we look like the upcoming
release has already been done.  "lsb_release -c" will then report
"bullsye".  However, there is some possibility this will confuse other
things, as this release technically hasn't been done.  I've proposed
that with

 https://review.opendev.org/c/openstack/diskimage-builder/+/787665

I'm open to suggestions!

-i