| Message ID | 20170719100802.14094-2-berrange@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 19.07.2017 12:08, Daniel P. Berrange wrote: > There is currently no explicit guidance on the duration of support > for features such as versioned machine types, which have a finite > useful lifespan. Thus apps / users cannot predict how much time > they might be able to use a feature for, before it is removed (if > ever). > > This adds a new appendix that lists items which have finite lifecycles, > such as machine types. For items which are generally expected to be > supported indefinitely, it sets out the policy around deprecation > and removal, should it be needed. > > Signed-off-by: Daniel P. Berrange <berrange@redhat.com> > --- > qemu-doc.texi | 37 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/qemu-doc.texi b/qemu-doc.texi > index 48af5155c7..200c0f7d0a 100644 > --- a/qemu-doc.texi > +++ b/qemu-doc.texi > @@ -38,6 +38,7 @@ > * QEMU Guest Agent:: > * QEMU User space emulator:: > * Implementation notes:: > +* Support lifetime:: > * License:: > * Index:: > @end menu > @@ -3128,6 +3129,42 @@ Run the emulation in single step mode. > > @include qemu-tech.texi > > +@node Support lifetime > +@appendix Support lifetime > + > +In general features are intended to be supported indefinitely once > +introduced into QEMU. > + > +In the event that a feature needs to be removed, it will be listed > +in the ``Deprecated features'' appendix of this document. The feature > +will remain functional for 2 releases prior to actual removal. > + > +Deprecated features may also generate warnings on the console when > +QEMU starts up, or if activated via a monitor command, however, > +this is not a mandatory requirement. Ack for the part above. I still think we should not auto-remove old machine types blindly, but take a little bit more care there... So maybe submit above part now for 2.10, to get that in and thus the clock running, and then let's discuss the machine type part again independently for 2.11? Thomas > +Certain features have an inherently finite lifetime, and thus > +will be removed on a fixed schedule, without following the normal > +deprecation process. Such features are listed in the sections > +that follow. > + > +@node Machine types > +@section Machine types > + > +For architectures which aim to support live migration compatibility > +across releases, each release will introduce a new versioned machine > +type. For example, the 2.8.0 release introduced machine types > +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures. > + > +To allow live migration of a guest running on a 2.8.0 release to a > +2.9.0, the QEMU 2.9.0 version must support the ``pc-i440fx-2.8'' and > +``pc-q35-2.8''. To allow users live migrating VMs to skip multiple > +intermediate releases when upgrading, new releases of QEMU will > +support machine types from many previous versions. > + > +The supported lifetime for versioned machine types is 12 releases, > +which is equivalent to 4 years worth of previous QEMU releases.
On 19/07/2017 13:56, Thomas Huth wrote: > +@node Machine types > +@section Machine types > + > +For architectures which aim to support live migration compatibility > +across releases, each release will introduce a new versioned machine > +type. For example, the 2.8.0 release introduced machine types > +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures. > + > +To allow live migration of a guest running on a 2.8.0 release to a > +2.9.0, the QEMU 2.9.0 version must support the ``pc-i440fx-2.8'' and > +``pc-q35-2.8''. To allow users live migrating VMs to skip multiple > +intermediate releases when upgrading, new releases of QEMU will > +support machine types from many previous versions. > + > +The supported lifetime for versioned machine types is 12 releases, > +which is equivalent to 4 years worth of previous QEMU releases. I think there's still no consensus on this. The first two paragraphs should be added to the documentation for -machine in qemu-options.hx, since "-machine [type=]foo" is currently not documented at all. Paolo
On Mon, Jul 24, 2017 at 03:49:29PM +0200, Paolo Bonzini wrote: > On 19/07/2017 13:56, Thomas Huth wrote: > > +@node Machine types > > +@section Machine types > > + > > +For architectures which aim to support live migration compatibility > > +across releases, each release will introduce a new versioned machine > > +type. For example, the 2.8.0 release introduced machine types > > +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures. > > + > > +To allow live migration of a guest running on a 2.8.0 release to a > > +2.9.0, the QEMU 2.9.0 version must support the ``pc-i440fx-2.8'' and > > +``pc-q35-2.8''. To allow users live migrating VMs to skip multiple > > +intermediate releases when upgrading, new releases of QEMU will > > +support machine types from many previous versions. > > + > > +The supported lifetime for versioned machine types is 12 releases, > > +which is equivalent to 4 years worth of previous QEMU releases. > > I think there's still no consensus on this. Indeed, which is exactly why I sent this patch - we need to come up with a sensible policy here, so we can stop repeating the same debate over & over & over each time some proposes a patch to kill off some random old machine type. The 12 release / 4 year figure was a fairly arbitrary starting point to which I'd be hoping to see critical reviewer feedback on (with possible counterproposals) so we can try to get something documented, to put an end to the repeated debates in this area each time someone proposes a patch. > The first two paragraphs > should be added to the documentation for -machine in qemu-options.hx, > since "-machine [type=]foo" is currently not documented at all. I'll happily send a patch for the docs for qemu-options.hx. Regards, Daniel
On 24/07/2017 16:11, Daniel P. Berrange wrote: >>> + >>> +The supported lifetime for versioned machine types is 12 releases, >>> +which is equivalent to 4 years worth of previous QEMU releases. >> I think there's still no consensus on this. > > Indeed, which is exactly why I sent this patch - we need to come up > with a sensible policy here, so we can stop repeating the same debate > over & over & over each time some proposes a patch to kill off some > random old machine type. > > The 12 release / 4 year figure was a fairly arbitrary starting > point to which I'd be hoping to see critical reviewer feedback > on (with possible counterproposals) so we can try to get something > documented, to put an end to the repeated debates in this area > each time someone proposes a patch. I agree. At the moment, the status is "machine types never die". We can change it, but I think that we should also make a decision on whether removing machine types implies removing properties that only exist for backwards-compatibility reasons. 4 year seems like a long time, but it can actually be pretty taxing for RHEL. I'm pretty sure that around RHEL 8.4 (some time between 2020-2022) we'll need a 1.5-ish machine type (2016). Paolo >> The first two paragraphs >> should be added to the documentation for -machine in qemu-options.hx, >> since "-machine [type=]foo" is currently not documented at all. > I'll happily send a patch for the docs for qemu-options.hx.
On Mon, Jul 24, 2017 at 04:26:24PM +0200, Paolo Bonzini wrote: > On 24/07/2017 16:11, Daniel P. Berrange wrote: > >>> + > >>> +The supported lifetime for versioned machine types is 12 releases, > >>> +which is equivalent to 4 years worth of previous QEMU releases. > >> I think there's still no consensus on this. > > > > Indeed, which is exactly why I sent this patch - we need to come up > > with a sensible policy here, so we can stop repeating the same debate > > over & over & over each time some proposes a patch to kill off some > > random old machine type. > > > > The 12 release / 4 year figure was a fairly arbitrary starting > > point to which I'd be hoping to see critical reviewer feedback > > on (with possible counterproposals) so we can try to get something > > documented, to put an end to the repeated debates in this area > > each time someone proposes a patch. > > I agree. At the moment, the status is "machine types never die". > > We can change it, but I think that we should also make a decision on > whether removing machine types implies removing properties that only > exist for backwards-compatibility reasons. > > 4 year seems like a long time, but it can actually be pretty taxing for > RHEL. I'm pretty sure that around RHEL 8.4 (some time between > 2020-2022) we'll need a 1.5-ish machine type (2016). QEMU 1.5 was 2013, so that's saying RHEL 8 will want support for QEMU machine types (and all their properties) that are ~10 years old from upstream QEMU POV. Possibly longer, as RHEL lifetime seems to only ever increase Generally I see the following choices: 1. Upstream never removes machine types or properties they use 2. Upstream removes machine types after N releases / Y years, but keeps properties related to them forever 3. Upstream removes machine types after N releases / Y years, & removes some associated properties at same time. 4. Upstream removes machine types after N releases / Y years, & optionally marks associated properties as deprecated, removing them in accordance with deprecation policy. Option 1 is current state of play, leaving burden on upstream forever, and letting machine list grow without bound. Option 2 stops the '-M ?' list growing without bound, but aside from that is the same as option 1. Not much difference from option 1, since supporting the properties is what adds the core maint burden, not the machine types themselves. Options 3/4 reduce burden on QEMU upstream, at cost of requiring the downstream vendor(s) to un-delete properties that upstream decides to remove and deal with any fallout that entails. The work involved in undeleting stuff is larger than the work involved in keeping it alive in upstream, because downstream has to undelete it, resolve conflicts, and then do all the same work upstream would have been doing had it not delete it & deal with further merge conflicts. Downstreams may not care about difference betweeen option 1 & 2 if they define their own custom machine types (RHEL & Ubuntu both do) Effectively it comes down to who should have the maint burden, upstream or downstream. If it takes more work downstream to undelete & maintain machine types in the downstream fork, that means downstream maintainers less free time to improve QEMU upstream. From that POV, deleting machine types & props upstream is actually counterproductive to upstream on balance. The rational thing would thus be to stick with status quo, and explicitly cdeclare that upstream will *never* delete machine types, or make their lifetime long enough for the longest lived downstream (10 years min & by the time we get to 10 years, it might even be 15 years). Regards, Daniel
On 24/07/2017 16:47, Daniel P. Berrange wrote: > If it takes more work downstream to undelete & maintain machine > types in the downstream fork, that means downstream maintainers > less free time to improve QEMU upstream. From that POV, deleting > machine types & props upstream is actually counterproductive to > upstream on balance. The rational thing would thus be to stick > with status quo, and explicitly cdeclare that upstream will *never* > delete machine types, or make their lifetime long enough for the > longest lived downstream (10 years min & by the time we get to > 10 years, it might even be 15 years). Yeah, that makes sense. At the moment at least Red Hat and Canonical create custom machine types. As soon as neither Red Hat nor Canonical contribute to upstream QEMU, the policy can change. But honestly, even though I have an obvious conflict of interest, I see no reason to make things more complicated for downstreams that are active contributors to QEMU... Paolo
diff --git a/qemu-doc.texi b/qemu-doc.texi index 48af5155c7..200c0f7d0a 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -38,6 +38,7 @@ * QEMU Guest Agent:: * QEMU User space emulator:: * Implementation notes:: +* Support lifetime:: * License:: * Index:: @end menu @@ -3128,6 +3129,42 @@ Run the emulation in single step mode. @include qemu-tech.texi +@node Support lifetime +@appendix Support lifetime + +In general features are intended to be supported indefinitely once +introduced into QEMU. + +In the event that a feature needs to be removed, it will be listed +in the ``Deprecated features'' appendix of this document. The feature +will remain functional for 2 releases prior to actual removal. + +Deprecated features may also generate warnings on the console when +QEMU starts up, or if activated via a monitor command, however, +this is not a mandatory requirement. + +Certain features have an inherently finite lifetime, and thus +will be removed on a fixed schedule, without following the normal +deprecation process. Such features are listed in the sections +that follow. + +@node Machine types +@section Machine types + +For architectures which aim to support live migration compatibility +across releases, each release will introduce a new versioned machine +type. For example, the 2.8.0 release introduced machine types +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures. + +To allow live migration of a guest running on a 2.8.0 release to a +2.9.0, the QEMU 2.9.0 version must support the ``pc-i440fx-2.8'' and +``pc-q35-2.8''. To allow users live migrating VMs to skip multiple +intermediate releases when upgrading, new releases of QEMU will +support machine types from many previous versions. + +The supported lifetime for versioned machine types is 12 releases, +which is equivalent to 4 years worth of previous QEMU releases. + @node License @appendix License
There is currently no explicit guidance on the duration of support for features such as versioned machine types, which have a finite useful lifespan. Thus apps / users cannot predict how much time they might be able to use a feature for, before it is removed (if ever). This adds a new appendix that lists items which have finite lifecycles, such as machine types. For items which are generally expected to be supported indefinitely, it sets out the policy around deprecation and removal, should it be needed. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- qemu-doc.texi | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)