Re: [PATCH] docs/about: Automatically deprecate versioned machine types older than 6 years
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.
Signed-off-by: Thomas Huth <thuth(a)redhat.com>
---
docs/about/deprecated.rst | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 6d595de3b6..fe69e2d44c 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -220,6 +220,17 @@ is a chance the code will bitrot without anyone noticing.
System emulator machines
------------------------
+Versioned machine types older than 6 years
+''''''''''''''''''''''''''''''''''''''''''
+
+Starting with the release of QEMU 10.0, versioned machine types older than
+6 years will automatically be considered as deprecated and might be due to
+removal without furthor notice. For example, this affects machine types like
+pc-i440fx-X.Y, pc-q35-X.Y, pseries-X.Y, s390-ccw-virtio-X.Y or virt-X.Y where
+X is the major number and Y is the minor number of the old QEMU version.
+If you are still using machine types from QEMU versions older than 6 years,
+please update your setting to use a newer versioned machine type instead.
+
Arm ``virt`` machine ``dtb-kaslr-seed`` property (since 7.1)
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
--
2.44.0
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 :|