Public bug reported: I wanted to request that ipxe-qemu-256k-compat inherits the MIR from ipxe where it was absed on. Since we knew this will show up we prepared (but were unable to open a bug until the new queue was passed), thereby this MIR is a bit special and does not hold the usual template.
Background: - IPXE (among other things) generates roms which are used by qemu - The size of these roms changed, and to get migrations working we need a compat package containing some old roms (details see pad.lv/1713490) Solution: - src:ipxe will contain the newest version as usual (in Main already, a merge to new version is prepared for Bionic) - there will be a copy+rename+reduce-content of the older src:ipxe uploaded under a new name being src:qemu-256k-compat - this is what will go to new queue and then needs an ack to go in main afterwards - This should be no (significant) extra effort for you because - the source of src:qemu-256k-compat is identical to the src:ipxe package - both are needed until any pre-Bionic is out of support - so we support this very same code for the same time anyway Around that a few discussions that I want to document here: # Discussion 1 - tyhicks > Just to be sure that I'm clear, we'll have two copies of the same > version of the IPXE source. In the case of a vulnerability in IPXE, > we'll need to fix it in both source packages? In case of a vulnerability in the src in xenial you'll have to fix: - src:ipxe in xenial-artful - src:ipxe-256k-compat in Bionic and later (same change as it is the same source) > Will there only be two IPXE source packages in Bionic? In other words, > will you drop src:qemu-256k-compat in Bionic+1? We can drop src:ipxe-256k-compat when we drop Xenial. Since it is the same source and the same time of support that should be small amount of extra work. #Discussion 2 - sarnold [...] This went on for a while discussing alternatives at what point we can drop the new -compat src package. It ended with Seth Concluding [...] I think VM migrations are different enough from release upgrades that it's fair to consider them seperately. We documented that we allow VM migration from LTS to LTS+2 on https://wiki.ubuntu.com/QemuKVMMigration#Support_Matrix -- it sounds like this decision was made with due deliberation, so I don't want to disrupt it without good reason. Is it a realistic upgrade path for a private cloud running one LTS to install new LTS+2 nodes and skip LTS+1? What does upgrading a private cloud look like? A "small" cloud with just libvirt and virsh could certainly be upgraded this way. Having to install an LTS+1 compute node just to migrate through on the way to LTS+2 compute nodes feels like an arbitrary and artificial limitation. Duplicating these ipxe roms in 18.04 LTS *and* 20.04 LTS is unfortunate. But the gain in flexibility may outweigh the maintainance costs. In any event we don't have to make a final decision on 20.04 LTS until 2020. At this point I think I'm on board with the duplicate source packages. ** Affects: ipxe-qemu-256k-compat (Ubuntu) Importance: High Status: Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1747358 Title: [MIR] ipxe-qemu-256k-compat To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ipxe-qemu-256k-compat/+bug/1747358/+subscriptions -- ubuntu-bugs mailing list firstname.lastname@example.org https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs