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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
