[PATCH] docs/about: Automatically deprecate versioned machine types older than 6 years
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@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
On Tue, 30 Apr 2024 at 07:45, Thomas Huth <thuth@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@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@linaro.org> thanks -- PMM
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@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@linaro.org>
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@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@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 :|
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
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@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 :|
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.
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@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 :|
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 :|
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
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 :|
participants (5)
-
Cédric Le Goater -
Daniel P. Berrangé -
Peter Maydell -
Philippe Mathieu-Daudé -
Thomas Huth