Package: release.debian.org Severity: normal Tags: bullseye User: release.debian....@packages.debian.org Usertags: pu X-Debbugs-Cc: cloud-i...@packages.debian.org, t...@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
