Bug#1070137: bullseye-pu: package cloud-init/22.4.2-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian.org@packages.debian.org
Usertags: pu
X-Debbugs-Cc: cloud-init@packages.debian.org, team@security.debian.org
Control: affects -1 + src:cloud-init
Hi folks. This isn't a straightforward stable proposed-updates
request, but I think starting with such a request is probably the
right approach...
The cloud team builds official Debian images for multiple cloud
environments, including OpenStack, Microsoft Azure, and Amazon EC2.
We support all supported stable releases, including those supported by
the LTS team. We build images including the backports kernels in
addition to the standard kernels.
To make a long story short, we build our Azure images with the
cloud-init package from bullseye-backports. Images targeting other
cloud environments use cloud-init from the main repo.
As bullseye-backports nears its EOL date, we're faced with the
possibility that our Azure images contain unsupportable packages, and
that eventually (when bullseye-backports is archived) we'll be unable
to build new images at all. These are scenarios we'd very much like
to avoid.
We've got at least a few options:
1. With an upcoming bullseye point release (how many more are there?)
we update cloud-init to the version that's in bookworm. This is
the 22.4.2 package, which is close to the 22.4.1 package we're
currently shipping on Azure. 22.4.2 is well tested in bookworm
across all major cloud services, though we have not performed any
major testing in a bullseye environment yet. For non Azure users,
this would be an update from version 20.4.2, which is a pretty
large change.
2. We introduce a new versioned cloud-init source and binary package
in the bullseye security archive, e.g. something like
cloud-init-22.4.1. This would look similar to what the kernel team
did with the linux-5.10 source package added to buster-security,
and which I assume they plan on doing with linux-6.1 in
bullseye-security. The cloud team would transition to this new
versioned package for the Azure images, but would continue using
the existing bullseye package everywhere else.
3. We do nothing, and leave the bullseye Azure users without a
supportable cloud-init package.
4. Something else?
There are pros and cons to each option. Given bullseye's age and
cloud-init's blast radius (a regression could potentially disrupt the
provisioning process of cloud VMs, which is particularly disruptive in
such environments) I lean toward option (2) above, as it minimizes the
changes. The obvious drawback is that we now have two versions of
cloud-init in the bullseye repositories, which was not the case
previously. The cloud team is committed to supporting this situation
for the duration of the bullseye LTS lifetime.
I realize that the security and release teams won't specifically care
what choice we make once bullseye's final point release is issued, but
I suspect you'll both have useful insights into how best to approach
this situation, and we may need your signoff ahead of that event
depending on which path we choose.
Thanks.
noah
Reply to: