1:45 a.m.
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.
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
4:32 a.m.
New subject: [PATCH] docs/about: Automatically deprecate versioned machine
types older than 6 years
On Tue, 30 Apr 2024 at 07:45, Thomas Huth <thuth(a)redhat.com> 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.
Sounds like a good idea.
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
"more than 6 years old"
+''''''''''''''''''''''''''''''''''''''''''
+
+Starting with the release of QEMU 10.0, versioned machine types older than
+6 years
ditto
will automatically be considered as deprecated and might be due to
+removal without furthor notice. For example, this affects machine
types like
"further"
+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,
ditto
+please update your setting to use a newer versioned machine type
instead.
+
Arm ``virt`` machine ``dtb-kaslr-seed`` property (since 7.1)
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Otherwise
Reviewed-by: Peter Maydell <peter.maydell(a)linaro.org>
thanks
-- PMM
4:40 a.m.
New subject: [PATCH] docs/about: Automatically deprecate versioned machine
types older than 6 years
Hi Thomas,
On 30/4/24 08:45, 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.
Thanks for taking that out of my plate :)
IIRC 6 years was because of some old RHEL version, otherwise could
5 years be enough? (maybe it could be good enough for this old RHEL
version as of QEMU v10.0).
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
Why can't we start with QEMU 9.1?
+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.
Reviewed-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
4:58 a.m.
New subject: [PATCH] docs/about: Automatically deprecate versioned machine
types older than 6 years
On Tue, Apr 30, 2024 at 11:40:42AM +0200, Philippe Mathieu-Daudé wrote:
Hi Thomas,
On 30/4/24 08:45, 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.
Thanks for taking that out of my plate :)
IIRC 6 years was because of some old RHEL version, otherwise could
5 years be enough? (maybe it could be good enough for this old RHEL
version as of QEMU v10.0).
With my RHEL hat on, 6 years gives an approximate alignment with
RHEL lifecycles, which have ended up being roughly 3 years apart.
RHEL-N, wants to support all machine types from RHEL-(N-1), so
in the worst case that gives up to 6 years worth of QEMU versions.
5 years could well be enough in many cases, depending on how
frequently RHEL rebases QEMU, but could also trip us up if the
timelines do something unexpected. So 6 years is a bit safer
from Red Hat's POV, if the community is willing.
> 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
Why can't we start with QEMU 9.1?
> +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.
Reviewed-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
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 :|
5:02 a.m.
New subject: [PATCH] docs/about: Automatically deprecate versioned machine
types older than 6 years
On 30/04/2024 11.40, Philippe Mathieu-Daudé wrote:
Hi Thomas,
On 30/4/24 08:45, 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.
Thanks for taking that out of my plate :)
IIRC 6 years was because of some old RHEL version, otherwise could
5 years be enough? (maybe it could be good enough for this old RHEL
version as of QEMU v10.0).
My thinking was like this:
1) We recently talked about marking all machine types up to 2.12 as
deprecated recently. 2.12 has been released in 2018, so if we feel confident
that those old machine types could go away now/soon, 2024 - 2018 = 6 years
seem to be a good rule of thumb.
2) RHEL and OpenSuSE tend to provide feature updates in their enterprise
distros for 5 (RHEL) or 6 (current OpenSuSE AFAIK) years, so keeping old
machine types in upstream QEMU for that amount of time certainly also helps
with downstream distros.
> 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
Why can't we start with QEMU 9.1?
If I put 9.1 now there, that would make it possible to immediately remove
machines in 9.2, i.e. we would skip the
must-be-marked-as-deprecated-for-two-releases rule here.
Thomas
4:45 a.m.
New subject: [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.
If anyone thinks 6 years is not very long, consider that this implies
QEMU will be maintaining *18* versions for each versioned machine type.
So across aarch64 'virt', x86 'pc' & 'q35', ppc
'spapr', s390x 'ccw',
and m68k 'virt', that's upto 108 machines we're keeping ABI preserved
for in the worst case...
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
How about:
s/6 years/6 years (equivalent to 18 releases)/
Also
s/as deprecated/deprecated/
s/due to/liable for/
+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,
Again
s/6 years/6 years (equivalent to 18 releases)/
+please update your setting to use a newer versioned machine type
instead.
s/setting/configuration/
+
Arm ``virt`` machine ``dtb-kaslr-seed`` property (since 7.1)
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
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 :|
4:58 a.m.
New subject: [PATCH] docs/about: Automatically deprecate versioned machine
types older than 6 years
On 4/30/24 11:45, 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.
If anyone thinks 6 years is not very long, consider that this implies
QEMU will be maintaining *18* versions for each versioned machine type.
So across aarch64 'virt', x86 'pc' & 'q35', ppc
'spapr', s390x 'ccw',
and m68k 'virt', that's upto 108 machines we're keeping ABI preserved
for in the worst case...
We will probably have RISC-V machines to support also. Anyhow, 6 years
looks good to me.
Thanks,
C.
4:55 a.m.
New subject: [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 :|
5:21 a.m.
New subject: [PATCH] docs/about: Automatically deprecate versioned machine
types older than 6 years
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 :|
5:29 a.m.
New subject: [PATCH] docs/about: Automatically deprecate versioned machine
types older than 6 years
On 30/04/2024 11.55, 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.
Sounds like a good idea, too! Since I have to drop this patch here anyway,
could you maybe write such a new patch? (or do you want me to try to
formulate this?)
Thomas
11:54 a.m.
New subject: [PATCH] docs/about: Automatically deprecate versioned machine
types older than 6 years
On Tue, Apr 30, 2024 at 12:29:14PM +0200, Thomas Huth wrote:
On 30/04/2024 11.55, 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.
Sounds like a good idea, too! Since I have to drop this patch here anyway,
could you maybe write such a new patch? (or do you want me to try to
formulate this?)
Yes, I'll send something for discussion soon.
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 :|
240
days inactive
240
days old
10 comments
5 participants
participants (5)
-
Cédric Le Goater -
Daniel P. Berrangé -
Peter Maydell -
Philippe Mathieu-Daudé -
Thomas Huth