On Tue, Apr 30, 2024 at 10:55:38AM +0100, Daniel P. Berrangé wrote:
On Tue, Apr 30, 2024 at 08:45:29AM +0200, Thomas Huth wrote:
Old machine types often have bugs or work-arounds that affect our possibilities to move forward with the QEMU code base (see for example https://gitlab.com/qemu-project/qemu/-/issues/2213 for a bug that likely cannot be fixed without breaking live migration with old machine types, or https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html or commit ea985d235b86). So instead of going through the process of manually deprecating old machine types again and again, let's rather add an entry that can stay, which declares that machine types older than 6 years are considered as deprecated automatically. Six years should be sufficient to support the release cycles of most Linux distributions.
Reading this again, I think we're mixing two concepts here.
With this 6 year cut off, we're declaring the actual *removal* date, not the deprecation date.
A deprecation is something that happens prior to removal normally, to give people a warning of /future/ removal, as a suggestion that they stop using it.
If we never set the 'deprecation_reason' on a machine type, then unless someone reads this doc, they'll never realize they are on a deprecated machine.
When it comes to machine types, I see deprecation as a way to tell people they should not deploy a /new/ VM on a machine type, only use it for back compat (incoming migration / restore from saved image) with existing deployed VMs.
If we delete a machine on the 6 year anniversary, then users don't want to be deploying /new/ VMs using that on the 5 year anniversary as it only gives a 1 year upgrade window.
So how long far back do we consider it reasonable for a user to deploy a /new/ VM on an old machine type ? 1 year, 2 years, 3 years ?
How about picking the half way point ? 3 years ?
ie, set deprecation_reason for any machine that is 3 years old, but declare that our deprecation cycle lasts for 3 years, instead of the normal 1 year, when applied to machine types.
This would give a strong hint that users should get off the old machine type, several years before its finally deleted.
The m68k/arm archs have a nice macro for defining versions that exposes major/minor directly. That would let us automatically set the deprecation flag after 3 years, avoiding manually writing patches for each release: diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 3c93c0c0a6..e40209f60a 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -101,6 +101,11 @@ static void arm_virt_compat_set(MachineClass *mc) arm_virt_compat_len); } +#define MACHINE_IS_DEPRECATED(major, minor) \ + ((QEMU_VERSION_MAJOR - major) > 3 || \ + ((QEMU_VERSION_MAJOR - major) == 3 && \ + (QEMU_VERSION_MINOR - minor) > 0)) + #define DEFINE_VIRT_MACHINE_LATEST(major, minor, latest) \ static void virt_##major##_##minor##_class_init(ObjectClass *oc, \ void *data) \ @@ -109,6 +114,9 @@ static void arm_virt_compat_set(MachineClass *mc) arm_virt_compat_set(mc); \ virt_machine_##major##_##minor##_options(mc); \ mc->desc = "QEMU " # major "." # minor " ARM Virtual Machine"; \ + if (MACHINE_IS_DEPRECATED(major, minor)) { \ + mc->deprecation_reason = "machine virt-" # major "." # minor " is not recommended for newly deployed VMs"; \ + } \ if (latest) { \ mc->alias = "virt"; \ } \ we could easily change other arches to enable the same thing. Then all we need do manually is the actual deletion. We would make it a BUILD_BUG_ON after say 20 releases to force us to remember the actual deletion at the 6 year point, without creating an immediate build fail in that exact 18th release cycle. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|