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@xxxxxxxxxx> > --- > 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 :| _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
