Message ID | 1494398933-8366-1-git-send-email-thuth@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote: > We don't want to carry along old machine types forever. If we are able to > remove the pc machines up to 0.13 one day for example, this would allow > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM > BARs directly to low memory). So let's start with a deprecation message > for the old 0.xx machine types so that the (hopefully) few users of these > old systems start switching over to newer machine types instead. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > Note: I've decided to print the warning for all pc-0.* machine types, > but that of course doesn't mean that we also have to remove them all at > once when we decide to finally really remove some. We could then also > start by removing 0.10 and 0.11 only, for example (since there should > really be no users left for these), or only up to 0.13 (to be able to > kill rombar=0), as discussed in the "Deprecating old machine types" > mail thread recently. As a point of reference here are the release dates: v0.10.0: Mar 2009 v0.11.0: Sep 2009 v0.12.0: Dec 2009 v0.13.0: Oct 2010 v0.14.0: Feb 2011 v0.15.0: Aug 2011 v1.0: Dec 2011 v1.1.0: Jun 2012 v1.2.0: Sep 2012 v1.3.0: Dec 2012 v1.4.0: Feb 2013 v1.5.0: May 2013 v1.6.0: Aug 2013 v1.7.0: Nov 2013 v2.0.0: Apr 2014 v2.1.0: Aug 2014 v2.2.0: Dec 2014 v2.3.0: Apr 2015 v2.4.0: Aug 2015 v2.5.0: Dec 2015 v2.6.0: May 2016 v2.7.0: Sep 2016 v2.8.0: Dec 2016 v2.9.0: Apr 2017 If we deprecate in this release (~Aug/Sep 2017), and kill in the next release (Dec 2017), that means our oldest machine type pc-1.0 is still going to be 6 years, or 18 major releases, old. This raises some questions - Do we really think that we still have users with VMs that are stuck on a 6 year old machine type from 18 major releases ago ? - Is 6 years / 18 major releases going to be our cutoff point for machine types going forward ? - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful unless someone can show automated testing results that confirm it is compatible. FYI, I'm in favour of culling old machine types, but I think when we do this it should not be a one-off ad-hoc culling. It should be accompanied by changes to the documentation that clearly state our official support policy for machine type lifetimes, so that users know what to expect for future releases. Also unless we're going to get more serious about automated testing to validate machine type compatibility between *all* previously releases, I think that 6 years / 18 releases is too long a time to have any confidence in migration compatibility between versions. IOW, I think you should be more aggressive in culling old machine types that this patch is... Regards, Daniel
On 10.05.2017 11:08, Daniel P. Berrange wrote: > On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote: >> We don't want to carry along old machine types forever. If we are able to >> remove the pc machines up to 0.13 one day for example, this would allow >> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM >> BARs directly to low memory). So let's start with a deprecation message >> for the old 0.xx machine types so that the (hopefully) few users of these >> old systems start switching over to newer machine types instead. >> >> Signed-off-by: Thomas Huth <thuth@redhat.com> >> --- >> Note: I've decided to print the warning for all pc-0.* machine types, >> but that of course doesn't mean that we also have to remove them all at >> once when we decide to finally really remove some. We could then also >> start by removing 0.10 and 0.11 only, for example (since there should >> really be no users left for these), or only up to 0.13 (to be able to >> kill rombar=0), as discussed in the "Deprecating old machine types" >> mail thread recently. > > > As a point of reference here are the release dates: > > v0.10.0: Mar 2009 > v0.11.0: Sep 2009 > v0.12.0: Dec 2009 > v0.13.0: Oct 2010 > v0.14.0: Feb 2011 > v0.15.0: Aug 2011 > v1.0: Dec 2011 > v1.1.0: Jun 2012 > v1.2.0: Sep 2012 > v1.3.0: Dec 2012 > v1.4.0: Feb 2013 > v1.5.0: May 2013 > v1.6.0: Aug 2013 > v1.7.0: Nov 2013 > v2.0.0: Apr 2014 > v2.1.0: Aug 2014 > v2.2.0: Dec 2014 > v2.3.0: Apr 2015 > v2.4.0: Aug 2015 > v2.5.0: Dec 2015 > v2.6.0: May 2016 > v2.7.0: Sep 2016 > v2.8.0: Dec 2016 > v2.9.0: Apr 2017 > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next > release (Dec 2017) There was kind of a consensus in the last thread in march that we should print out the deprecation message for at least two releases, so that users have at least one release cycle to object before a feature gets really removed. > that means our oldest machine type pc-1.0 is still > going to be 6 years, or 18 major releases, old. This raises some questions > > - Do we really think that we still have users with VMs that are > stuck on a 6 year old machine type from 18 major releases ago ? > > - Is 6 years / 18 major releases going to be our cutoff point for > machine types going forward ? > > - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is > migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful > unless someone can show automated testing results that confirm > it is compatible. See https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg05837.html ... there might be still users of 0.12 and 1.0 (though I don't hope so), and everything before QEMU 1.2 can't be (life-)migrated anymore, so we can nuke 0.10 and 0.11 for sure, maybe also the others up to 1.2. So starting with a deprecation warning for 0.xx sounded like a good idea to me. > FYI, I'm in favour of culling old machine types, but I think when we do > this it should not be a one-off ad-hoc culling. > > It should be accompanied by changes to the documentation that clearly > state our official support policy for machine type lifetimes, so that > users know what to expect for future releases. Sounds like an idea, could you please propose such a patch to the documentation? > Also unless we're going to get more serious about automated testing to > validate machine type compatibility between *all* previously releases, > I think that 6 years / 18 releases is too long a time to have any > confidence in migration compatibility between versions. Distro vendors often offer 5 - 10 years support for certain versions of their Linux distros, so I think we should at least support 5 years, too. > IOW, I think you should be more aggressive in culling old machine types > that this patch is... Actually, I like the idea of using the major release versions for defining the set of removal - hoping that we will do a v3.0 next year which then would support the previous two major release versions 1.x and 2.x, but drops support for the 0.xx versions completely ... Thomas
On Wed, May 10, 2017 at 12:05:16PM +0200, Thomas Huth wrote: > On 10.05.2017 11:08, Daniel P. Berrange wrote: > > On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote: > >> We don't want to carry along old machine types forever. If we are able to > >> remove the pc machines up to 0.13 one day for example, this would allow > >> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM > >> BARs directly to low memory). So let's start with a deprecation message > >> for the old 0.xx machine types so that the (hopefully) few users of these > >> old systems start switching over to newer machine types instead. > >> > >> Signed-off-by: Thomas Huth <thuth@redhat.com> > >> --- > >> Note: I've decided to print the warning for all pc-0.* machine types, > >> but that of course doesn't mean that we also have to remove them all at > >> once when we decide to finally really remove some. We could then also > >> start by removing 0.10 and 0.11 only, for example (since there should > >> really be no users left for these), or only up to 0.13 (to be able to > >> kill rombar=0), as discussed in the "Deprecating old machine types" > >> mail thread recently. > > > > > > As a point of reference here are the release dates: > > > > v0.10.0: Mar 2009 > > v0.11.0: Sep 2009 > > v0.12.0: Dec 2009 > > v0.13.0: Oct 2010 > > v0.14.0: Feb 2011 > > v0.15.0: Aug 2011 > > v1.0: Dec 2011 > > v1.1.0: Jun 2012 > > v1.2.0: Sep 2012 > > v1.3.0: Dec 2012 > > v1.4.0: Feb 2013 > > v1.5.0: May 2013 > > v1.6.0: Aug 2013 > > v1.7.0: Nov 2013 > > v2.0.0: Apr 2014 > > v2.1.0: Aug 2014 > > v2.2.0: Dec 2014 > > v2.3.0: Apr 2015 > > v2.4.0: Aug 2015 > > v2.5.0: Dec 2015 > > v2.6.0: May 2016 > > v2.7.0: Sep 2016 > > v2.8.0: Dec 2016 > > v2.9.0: Apr 2017 > > > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next > > release (Dec 2017) > > There was kind of a consensus in the last thread in march that we should > print out the deprecation message for at least two releases, so that > users have at least one release cycle to object before a feature gets > really removed. For removal of machine types, IMHO, I don't think we should consider objections. Just clearly document the lifecycle so people know exactly how long they have until end-of-life, right from the moment they deploy, and thus won't be surprised when we remove it. > > that means our oldest machine type pc-1.0 is still > > going to be 6 years, or 18 major releases, old. This raises some questions > > > > - Do we really think that we still have users with VMs that are > > stuck on a 6 year old machine type from 18 major releases ago ? > > > > - Is 6 years / 18 major releases going to be our cutoff point for > > machine types going forward ? > > > > - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is > > migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful > > unless someone can show automated testing results that confirm > > it is compatible. > > See https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg05837.html > ... there might be still users of 0.12 and 1.0 (though I don't hope > so), and everything before QEMU 1.2 can't be (life-)migrated anymore, so > we can nuke 0.10 and 0.11 for sure, maybe also the others up to 1.2. > So starting with a deprecation warning for 0.xx sounded like a good idea > to me. If 1.2 and old is known to be broken we should just deprecate those immediately now. It is pointless keeping something around that is known broken. > > FYI, I'm in favour of culling old machine types, but I think when we do > > this it should not be a one-off ad-hoc culling. > > > > It should be accompanied by changes to the documentation that clearly > > state our official support policy for machine type lifetimes, so that > > users know what to expect for future releases. > > Sounds like an idea, could you please propose such a patch to the > documentation? Yep. > > Also unless we're going to get more serious about automated testing to > > validate machine type compatibility between *all* previously releases, > > I think that 6 years / 18 releases is too long a time to have any > > confidence in migration compatibility between versions. > > Distro vendors often offer 5 - 10 years support for certain versions of > their Linux distros, so I think we should at least support 5 years, too. We have two distinct needs in that area. RHEL has ignored upstream machine types & defined its own forever, so we don't need to keep pc-xxxx machines around to help RHEL. Ubuntu has more recently started defining custom machine types too. If, however, we also started deleting the underlying features (rombar=0) that RHEL needs in order to create its custom machine types, then that would cause downstream problems. For example RHEL-7.4 with QEMU 2.9.0 tries to provide a "rhel6.0.0" machine type for compatibility with old QEMU 0.12 version it orginally shipped. So while we can delete pc-0.12, we can't delete associated features needed by pc-0.12, without complicating RHEL's ability to create its back-compat machine types. Downstream would have to un-delete the features. > > IOW, I think you should be more aggressive in culling old machine types > > that this patch is... > > Actually, I like the idea of using the major release versions for > defining the set of removal - hoping that we will do a v3.0 next year > which then would support the previous two major release versions 1.x and > 2.x, but drops support for the 0.xx versions completely ... I think tieing removal to major versions is a mistake, unless we're going to set a fixed timeframe for delivery of major versions. ie if we gaurantee that we'll ship a new major version every 18 months, that gives people a predictable lifetime. If we carry on inventing reasons for major versions at arbitrary points in time, it makes it difficult to have any reasonable forward planning. It is more users friendly if we can set a clear fixed timeframe for machine type lifecycle / eol Regards, Daniel
On 10.05.2017 12:31, Daniel P. Berrange wrote: > On Wed, May 10, 2017 at 12:05:16PM +0200, Thomas Huth wrote: >> On 10.05.2017 11:08, Daniel P. Berrange wrote: [...] >>> - Do we really think that we still have users with VMs that are >>> stuck on a 6 year old machine type from 18 major releases ago ? >>> >>> - Is 6 years / 18 major releases going to be our cutoff point for >>> machine types going forward ? >>> >>> - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is >>> migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful >>> unless someone can show automated testing results that confirm >>> it is compatible. >> >> See https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg05837.html >> ... there might be still users of 0.12 and 1.0 (though I don't hope >> so), and everything before QEMU 1.2 can't be (life-)migrated anymore, so >> we can nuke 0.10 and 0.11 for sure, maybe also the others up to 1.2. >> So starting with a deprecation warning for 0.xx sounded like a good idea >> to me. > > If 1.2 and old is known to be broken we should just deprecate those > immediately now. It is pointless keeping something around that is > known broken. Thinking about this again - yeah, you're right. I'll send a v2 of my patch that deprecates 1.0 - 1.2, too. >>> Also unless we're going to get more serious about automated testing to >>> validate machine type compatibility between *all* previously releases, >>> I think that 6 years / 18 releases is too long a time to have any >>> confidence in migration compatibility between versions. >> >> Distro vendors often offer 5 - 10 years support for certain versions of >> their Linux distros, so I think we should at least support 5 years, too. > > We have two distinct needs in that area. > > RHEL has ignored upstream machine types & defined its own forever, so > we don't need to keep pc-xxxx machines around to help RHEL. Ubuntu has > more recently started defining custom machine types too. > > If, however, we also started deleting the underlying features (rombar=0) > that RHEL needs in order to create its custom machine types, then that > would cause downstream problems. For example RHEL-7.4 with QEMU 2.9.0 > tries to provide a "rhel6.0.0" machine type for compatibility with > old QEMU 0.12 version it orginally shipped. But isn't the whole point of deprecating features in upstream that we can get rid of this legacy cruft like rombar=0 ? Also, how do you determine whether you can finally remove such a feature from the upstream code? Go through all long-term supported distros and ask around? I think that is not really feasible... > So while we can delete pc-0.12, we can't delete associated features needed > by pc-0.12, without complicating RHEL's ability to create its back-compat > machine types. Downstream would have to un-delete the features. So I guess this is why Paolo said that pc-0.12 is still in "use" ... I think removing pc-0.12, but not removing rombar=0 will cause confusion in the upstream code base sooner or later, so I guess we should rather keep the pc-0.12 machine until we can get rid of it together with the rombar code. We should still mark it as deprecated, of course. >>> IOW, I think you should be more aggressive in culling old machine types >>> that this patch is... >> >> Actually, I like the idea of using the major release versions for >> defining the set of removal - hoping that we will do a v3.0 next year >> which then would support the previous two major release versions 1.x and >> 2.x, but drops support for the 0.xx versions completely ... > > I think tieing removal to major versions is a mistake, unless we're > going to set a fixed timeframe for delivery of major versions. ie if > we gaurantee that we'll ship a new major version every 18 months, that > gives people a predictable lifetime. If we carry on inventing reasons > for major versions at arbitrary points in time, it makes it difficult > to have any reasonable forward planning. It is more users friendly if > we can set a clear fixed timeframe for machine type lifecycle / eol IMHO we should have a new major release after we've reached a .9 minor release, but so far it seems like I'm the only one with that wish... Thomas
* Daniel P. Berrange (berrange@redhat.com) wrote: > On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote: > > We don't want to carry along old machine types forever. If we are able to > > remove the pc machines up to 0.13 one day for example, this would allow > > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM > > BARs directly to low memory). So let's start with a deprecation message > > for the old 0.xx machine types so that the (hopefully) few users of these > > old systems start switching over to newer machine types instead. > > > > Signed-off-by: Thomas Huth <thuth@redhat.com> > > --- > > Note: I've decided to print the warning for all pc-0.* machine types, > > but that of course doesn't mean that we also have to remove them all at > > once when we decide to finally really remove some. We could then also > > start by removing 0.10 and 0.11 only, for example (since there should > > really be no users left for these), or only up to 0.13 (to be able to > > kill rombar=0), as discussed in the "Deprecating old machine types" > > mail thread recently. > > > As a point of reference here are the release dates: > > v0.10.0: Mar 2009 > v0.11.0: Sep 2009 > v0.12.0: Dec 2009 > v0.13.0: Oct 2010 > v0.14.0: Feb 2011 > v0.15.0: Aug 2011 > v1.0: Dec 2011 > v1.1.0: Jun 2012 > v1.2.0: Sep 2012 > v1.3.0: Dec 2012 > v1.4.0: Feb 2013 > v1.5.0: May 2013 > v1.6.0: Aug 2013 > v1.7.0: Nov 2013 > v2.0.0: Apr 2014 > v2.1.0: Aug 2014 > v2.2.0: Dec 2014 > v2.3.0: Apr 2015 > v2.4.0: Aug 2015 > v2.5.0: Dec 2015 > v2.6.0: May 2016 > v2.7.0: Sep 2016 > v2.8.0: Dec 2016 > v2.9.0: Apr 2017 > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next > release (Dec 2017), that means our oldest machine type pc-1.0 is still > going to be 6 years, or 18 major releases, old. This raises some questions > > - Do we really think that we still have users with VMs that are > stuck on a 6 year old machine type from 18 major releases ago ? Our RHEL6 users are still on a 0.12 derivative. > - Is 6 years / 18 major releases going to be our cutoff point for > machine types going forward ? > > - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is > migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful > unless someone can show automated testing results that confirm > it is compatible. I'll give you a manual one; I just migrated: /opt/qemu/v1.0.1/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic to /opt/qemu/v2.9.0/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic -incoming tcp::4444 seems to have survived. Not exactly conclusive or heavy coverage, but it's not completely broken. > FYI, I'm in favour of culling old machine types, but I think when we do > this it should not be a one-off ad-hoc culling. > > It should be accompanied by changes to the documentation that clearly > state our official support policy for machine type lifetimes, so that > users know what to expect for future releases. > > Also unless we're going to get more serious about automated testing to > validate machine type compatibility between *all* previously releases, > I think that 6 years / 18 releases is too long a time to have any > confidence in migration compatibility between versions. The problem is we don't do that much testing; I know of more subtle things that have broken between 2.6 and 2.7 - so do you kill 2.6 machine type? No, but it's a question of how you choose what to kill. > IOW, I think you should be more aggressive in culling old machine types > that this patch is... Dave > 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 :| > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berrange@redhat.com) wrote: > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next > > release (Dec 2017), that means our oldest machine type pc-1.0 is still > > going to be 6 years, or 18 major releases, old. This raises some questions > > > > - Do we really think that we still have users with VMs that are > > stuck on a 6 year old machine type from 18 major releases ago ? > > Our RHEL6 users are still on a 0.12 derivative. Yep, but not using upstream machine types. So we can kill machine types without affecting RHEL-6. The separate question is whether we can kill the associated features that are needed for RHEL to create its legacy machine types (eg the rombar setting mentioned) > > > - Is 6 years / 18 major releases going to be our cutoff point for > > machine types going forward ? > > > > - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is > > migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful > > unless someone can show automated testing results that confirm > > it is compatible. > > I'll give you a manual one; I just migrated: > /opt/qemu/v1.0.1/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic > to > /opt/qemu/v2.9.0/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic -incoming tcp::4444 > > seems to have survived. > Not exactly conclusive or heavy coverage, but it's not completely > broken. > > > FYI, I'm in favour of culling old machine types, but I think when we do > > this it should not be a one-off ad-hoc culling. > > > > It should be accompanied by changes to the documentation that clearly > > state our official support policy for machine type lifetimes, so that > > users know what to expect for future releases. > > > > Also unless we're going to get more serious about automated testing to > > validate machine type compatibility between *all* previously releases, > > I think that 6 years / 18 releases is too long a time to have any > > confidence in migration compatibility between versions. > > The problem is we don't do that much testing; I know of more subtle > things that have broken between 2.6 and 2.7 - so do you kill 2.6 machine > type? No, but it's a question of how you choose what to kill. You know of the breaks between 2.6 & 2.7 because those are modern versions people are using & thus getting lots of attention & analysis from yourself and other people. Arguably it just looks worse because no one is actively using, testing or analysing 1.0 vs 2.7. Ideally, we would only claim to support combinations that we have active compatibility test coverage for. We lacking right now, but for the sake of discussion, lets assume we did have some level of automated coverage. Then there's still the question of how far back we want to be running the testing for. I think the latter is the more important question, as it sets us a clear process to follow, as well as a goal to reach for testing coverage. IOW, we should be able to set ourselves a goal / process, even if we don't yet achieve that in terms of testing. Regards, Daniel
On 10/05/2017 16:51, Dr. David Alan Gilbert wrote: > I'll give you a manual one; I just migrated: > /opt/qemu/v1.0.1/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic > to > /opt/qemu/v2.9.0/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic -incoming tcp::4444 > > seems to have survived. > Not exactly conclusive or heavy coverage, but it's not completely > broken. Yeah, I think resetting the VM will fail, or something like that. Paolo
* Daniel P. Berrange (berrange@redhat.com) wrote: > On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote: > > * Daniel P. Berrange (berrange@redhat.com) wrote: > > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next > > > release (Dec 2017), that means our oldest machine type pc-1.0 is still > > > going to be 6 years, or 18 major releases, old. This raises some questions > > > > > > - Do we really think that we still have users with VMs that are > > > stuck on a 6 year old machine type from 18 major releases ago ? > > > > Our RHEL6 users are still on a 0.12 derivative. > > Yep, but not using upstream machine types. So we can kill machine > types without affecting RHEL-6. The separate question is whether > we can kill the associated features that are needed for RHEL to > create its legacy machine types (eg the rombar setting mentioned) Right, it just felt a bit odd to kill it off upstream if we know of users ourselves who use old versions like that. Also remember machine types are not just about migration compatibility; if we kill a machine type then: a) The users will need to modify their libvirt xml for each VM to change machine type b) That change in guest view of the machine might upset the OS installed. I've certainly got VMs that were installed ages ago and are still using the XML from the old installation; so that probably means using an old machine type on a modern QEMU. Dave > > > > > - Is 6 years / 18 major releases going to be our cutoff point for > > > machine types going forward ? > > > > > > - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is > > > migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful > > > unless someone can show automated testing results that confirm > > > it is compatible. > > > > I'll give you a manual one; I just migrated: > > /opt/qemu/v1.0.1/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic > > to > > /opt/qemu/v2.9.0/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic -incoming tcp::4444 > > > > seems to have survived. > > Not exactly conclusive or heavy coverage, but it's not completely > > broken. > > > > > FYI, I'm in favour of culling old machine types, but I think when we do > > > this it should not be a one-off ad-hoc culling. > > > > > > It should be accompanied by changes to the documentation that clearly > > > state our official support policy for machine type lifetimes, so that > > > users know what to expect for future releases. > > > > > > Also unless we're going to get more serious about automated testing to > > > validate machine type compatibility between *all* previously releases, > > > I think that 6 years / 18 releases is too long a time to have any > > > confidence in migration compatibility between versions. > > > > The problem is we don't do that much testing; I know of more subtle > > things that have broken between 2.6 and 2.7 - so do you kill 2.6 machine > > type? No, but it's a question of how you choose what to kill. > > You know of the breaks between 2.6 & 2.7 because those are modern versions > people are using & thus getting lots of attention & analysis from yourself > and other people. Arguably it just looks worse because no one is actively > using, testing or analysing 1.0 vs 2.7. > > Ideally, we would only claim to support combinations that we have active > compatibility test coverage for. We lacking right now, but for the sake > of discussion, lets assume we did have some level of automated coverage. > Then there's still the question of how far back we want to be running the > testing for. I think the latter is the more important question, as it sets > us a clear process to follow, as well as a goal to reach for testing coverage. > > IOW, we should be able to set ourselves a goal / process, even if we don't > yet achieve that in terms of testing. > > 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 :| -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
Thomas Huth <thuth@redhat.com> writes: > On 10.05.2017 11:08, Daniel P. Berrange wrote: >> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote: [...] >> Also unless we're going to get more serious about automated testing to >> validate machine type compatibility between *all* previously releases, >> I think that 6 years / 18 releases is too long a time to have any >> confidence in migration compatibility between versions. Seconded. > Distro vendors often offer 5 - 10 years support for certain versions of > their Linux distros, so I think we should at least support 5 years, too. Non sequitur. Distro vendors put in serious work to keep versions working for 5 - 10 years. We can't, and we don't. All we do is try not to break things, which is nice, and helps the distro vendors some, but a far cry from anything I'd dare call "support". Perhaps an argument could be made that us keeping to try for at least 5 years would help distro vendors enough to be worthwhile. Maybe, but color me skeptic. >> IOW, I think you should be more aggressive in culling old machine types >> that this patch is... > > Actually, I like the idea of using the major release versions for > defining the set of removal - hoping that we will do a v3.0 next year > which then would support the previous two major release versions 1.x and > 2.x, but drops support for the 0.xx versions completely ... I wouldn't put *that* much weight into our past version numbers. If I remember correctly, there was no more to 1.0 than a feeling of "this 0.x thing is getting ridiculous".
On 10/05/2017 17:37, Markus Armbruster wrote: > Distro vendors put in serious work to keep versions working for 5 - 10 > years. We can't, and we don't. All we do is try not to break things, > which is nice, and helps the distro vendors some, but a far cry from > anything I'd dare call "support". > > Perhaps an argument could be made that us keeping to try for at least 5 > years would help distro vendors enough to be worthwhile. Maybe, but > color me skeptic. It's the opposite. Distro vendors care about it, so it is at least plausible to have things work from 5 years back, even if we don't test it. Of course there will be bugs and corner cases. Paolo
On 10/05/2017 16:47, Thomas Huth wrote: >> So while we can delete pc-0.12, we can't delete associated features needed >> by pc-0.12, without complicating RHEL's ability to create its back-compat >> machine types. Downstream would have to un-delete the features. > > So I guess this is why Paolo said that pc-0.12 is still in "use" ... I > think removing pc-0.12, but not removing rombar=0 will cause confusion > in the upstream code base sooner or later, I agree. > so I guess we should rather > keep the pc-0.12 machine until we can get rid of it together with the > rombar code. We should still mark it as deprecated, of course. > >> I think tieing removal to major versions is a mistake, unless we're >> going to set a fixed timeframe for delivery of major versions. ie if >> we gaurantee that we'll ship a new major version every 18 months, that >> gives people a predictable lifetime. If we carry on inventing reasons >> for major versions at arbitrary points in time, it makes it difficult >> to have any reasonable forward planning. It is more users friendly if >> we can set a clear fixed timeframe for machine type lifecycle / eol > > IMHO we should have a new major release after we've reached a .9 minor > release, but so far it seems like I'm the only one with that wish... I actually like that, but then you've pretty much guaranteed that you _cannot_ remove anything deprecated until 4.0. You and Daniel aren't disagreeing as heavily as it seems, I think. Paolo
* Markus Armbruster (armbru@redhat.com) wrote: > Thomas Huth <thuth@redhat.com> writes: > > > On 10.05.2017 11:08, Daniel P. Berrange wrote: > >> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote: > [...] > >> Also unless we're going to get more serious about automated testing to > >> validate machine type compatibility between *all* previously releases, > >> I think that 6 years / 18 releases is too long a time to have any > >> confidence in migration compatibility between versions. > > Seconded. > > > Distro vendors often offer 5 - 10 years support for certain versions of > > their Linux distros, so I think we should at least support 5 years, too. > > Non sequitur. > > Distro vendors put in serious work to keep versions working for 5 - 10 > years. We can't, and we don't. All we do is try not to break things, > which is nice, and helps the distro vendors some, but a far cry from > anything I'd dare call "support". > > Perhaps an argument could be made that us keeping to try for at least 5 > years would help distro vendors enough to be worthwhile. Maybe, but > color me skeptic. Since I'm often the one having to fix the breakages when we find they've diverged, I would prefer us to try to keep them working upstream. Every time something slips through upstream it's more work for me. Dave > >> IOW, I think you should be more aggressive in culling old machine types > >> that this patch is... > > > > Actually, I like the idea of using the major release versions for > > defining the set of removal - hoping that we will do a v3.0 next year > > which then would support the previous two major release versions 1.x and > > 2.x, but drops support for the 0.xx versions completely ... > > I wouldn't put *that* much weight into our past version numbers. If I > remember correctly, there was no more to 1.0 than a feeling of "this 0.x > thing is getting ridiculous". > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
Paolo Bonzini <pbonzini@redhat.com> writes: > On 10/05/2017 16:47, Thomas Huth wrote: >>> So while we can delete pc-0.12, we can't delete associated features needed >>> by pc-0.12, without complicating RHEL's ability to create its back-compat >>> machine types. Downstream would have to un-delete the features. >> >> So I guess this is why Paolo said that pc-0.12 is still in "use" ... I >> think removing pc-0.12, but not removing rombar=0 will cause confusion >> in the upstream code base sooner or later, > > I agree. > >> so I guess we should rather >> keep the pc-0.12 machine until we can get rid of it together with the >> rombar code. We should still mark it as deprecated, of course. >> >>> I think tieing removal to major versions is a mistake, unless we're >>> going to set a fixed timeframe for delivery of major versions. ie if >>> we gaurantee that we'll ship a new major version every 18 months, that >>> gives people a predictable lifetime. If we carry on inventing reasons >>> for major versions at arbitrary points in time, it makes it difficult >>> to have any reasonable forward planning. It is more users friendly if >>> we can set a clear fixed timeframe for machine type lifecycle / eol >> >> IMHO we should have a new major release after we've reached a .9 minor >> release, but so far it seems like I'm the only one with that wish... > > I actually like that, but then you've pretty much guaranteed that you > _cannot_ remove anything deprecated until 4.0. You and Daniel aren't > disagreeing as heavily as it seems, I think. Even better: drop the '.', and stop worrying about having to wait for some arbitrary number to come up before you're allowed to do something ;)
"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: > * Markus Armbruster (armbru@redhat.com) wrote: >> Thomas Huth <thuth@redhat.com> writes: >> >> > On 10.05.2017 11:08, Daniel P. Berrange wrote: >> >> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote: >> [...] >> >> Also unless we're going to get more serious about automated testing to >> >> validate machine type compatibility between *all* previously releases, >> >> I think that 6 years / 18 releases is too long a time to have any >> >> confidence in migration compatibility between versions. >> >> Seconded. >> >> > Distro vendors often offer 5 - 10 years support for certain versions of >> > their Linux distros, so I think we should at least support 5 years, too. >> >> Non sequitur. >> >> Distro vendors put in serious work to keep versions working for 5 - 10 >> years. We can't, and we don't. All we do is try not to break things, >> which is nice, and helps the distro vendors some, but a far cry from >> anything I'd dare call "support". >> >> Perhaps an argument could be made that us keeping to try for at least 5 >> years would help distro vendors enough to be worthwhile. Maybe, but >> color me skeptic. > > Since I'm often the one having to fix the breakages when we find they've > diverged, I would prefer us to try to keep them working upstream. > Every time something slips through upstream it's more work for me. I figure when downstream rebases from upstream version V to V+3, then upstream having tried not to break things for three versions back helps, but from that fork on, the value of upstream trying diminishes sharply. That makes me doubt the idea that upstream should try for as long as any downstream version exists ("at least 5 years"). Until downstreams rebase makes more sense to me.
On 11.05.2017 09:06, Markus Armbruster wrote: > Paolo Bonzini <pbonzini@redhat.com> writes: > >> On 10/05/2017 16:47, Thomas Huth wrote: >>>> So while we can delete pc-0.12, we can't delete associated features needed >>>> by pc-0.12, without complicating RHEL's ability to create its back-compat >>>> machine types. Downstream would have to un-delete the features. >>> >>> So I guess this is why Paolo said that pc-0.12 is still in "use" ... I >>> think removing pc-0.12, but not removing rombar=0 will cause confusion >>> in the upstream code base sooner or later, >> >> I agree. >> >>> so I guess we should rather >>> keep the pc-0.12 machine until we can get rid of it together with the >>> rombar code. We should still mark it as deprecated, of course. >>> >>>> I think tieing removal to major versions is a mistake, unless we're >>>> going to set a fixed timeframe for delivery of major versions. ie if >>>> we gaurantee that we'll ship a new major version every 18 months, that >>>> gives people a predictable lifetime. If we carry on inventing reasons >>>> for major versions at arbitrary points in time, it makes it difficult >>>> to have any reasonable forward planning. It is more users friendly if >>>> we can set a clear fixed timeframe for machine type lifecycle / eol >>> >>> IMHO we should have a new major release after we've reached a .9 minor >>> release, but so far it seems like I'm the only one with that wish... >> >> I actually like that, but then you've pretty much guaranteed that you >> _cannot_ remove anything deprecated until 4.0. You and Daniel aren't >> disagreeing as heavily as it seems, I think. > > Even better: drop the '.', and stop worrying about having to wait for > some arbitrary number to come up before you're allowed to do something > ;) I agree, we shouldn't limit ourselves by saying that we can only remove things when switching to a new major release. But I still think that also having "regular" major releases (e.g. after each .9 minor release) could also help us to remind ourselves to do some bigger (and likely necessary) spring-cleaning regularly. Thomas
"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: > * Daniel P. Berrange (berrange@redhat.com) wrote: >> On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote: >> > * Daniel P. Berrange (berrange@redhat.com) wrote: >> > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next >> > > release (Dec 2017), that means our oldest machine type pc-1.0 is still >> > > going to be 6 years, or 18 major releases, old. This raises some questions >> > > >> > > - Do we really think that we still have users with VMs that are >> > > stuck on a 6 year old machine type from 18 major releases ago ? >> > >> > Our RHEL6 users are still on a 0.12 derivative. >> >> Yep, but not using upstream machine types. So we can kill machine >> types without affecting RHEL-6. The separate question is whether >> we can kill the associated features that are needed for RHEL to >> create its legacy machine types (eg the rombar setting mentioned) > > Right, it just felt a bit odd to kill it off upstream if we know > of users ourselves who use old versions like that. > > Also remember machine types are not just about migration compatibility; > if we kill a machine type then: > a) The users will need to modify their libvirt xml for each VM to > change machine type Point taken. But if this inconvenience is unacceptable, consider an enterprise distribution, or maybe CentOS. > b) That change in guest view of the machine might upset the OS > installed. Unlikely, unless you migrate without a reboot. Guests almost always adapt to minor hardware changes on reboot just fine. > I've certainly got VMs that were installed ages ago and are still using > the XML from the old installation; so that probably means using an old > machine type on a modern QEMU. Eventually, that becomes as likely to actually work as rebooting with a newer machine type :)
On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote: > > > On 10/05/2017 16:47, Thomas Huth wrote: > >> So while we can delete pc-0.12, we can't delete associated features needed > >> by pc-0.12, without complicating RHEL's ability to create its back-compat > >> machine types. Downstream would have to un-delete the features. > > > > So I guess this is why Paolo said that pc-0.12 is still in "use" ... I > > think removing pc-0.12, but not removing rombar=0 will cause confusion > > in the upstream code base sooner or later, > > I agree. > > > so I guess we should rather > > keep the pc-0.12 machine until we can get rid of it together with the > > rombar code. We should still mark it as deprecated, of course. > > > >> I think tieing removal to major versions is a mistake, unless we're > >> going to set a fixed timeframe for delivery of major versions. ie if > >> we gaurantee that we'll ship a new major version every 18 months, that > >> gives people a predictable lifetime. If we carry on inventing reasons > >> for major versions at arbitrary points in time, it makes it difficult > >> to have any reasonable forward planning. It is more users friendly if > >> we can set a clear fixed timeframe for machine type lifecycle / eol > > > > IMHO we should have a new major release after we've reached a .9 minor > > release, but so far it seems like I'm the only one with that wish... > > I actually like that, but then you've pretty much guaranteed that you > _cannot_ remove anything deprecated until 4.0. You and Daniel aren't > disagreeing as heavily as it seems, I think. I don't think we should tie removal of features to version numbers. IMHO we should just increment the first major digit on a fixed time scale, either once a year, or whenever we get past .9. For removal of features, IMHO, the only important thing is to give users deprecation clear warning for 2-3 releases, and ensure feature detection works well. As long as that is done, there shouldn't be any need to batch them up for "major" releases. From libvirt POV, batching up removal to major releases is not beneficial. Batching to major releases gives a very inconsistent timeframe for removal too - somethign fdeprecated in .1 release may live on for years, until the next $major.0, while something deprecated in a .9 release can be killed in 4 months. I much prefer to see a consistent deprecated for 2 releases / 8 months, then deleted regardless of feature. Regards, Daniel
"Daniel P. Berrange" <berrange@redhat.com> writes: > On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote: >> >> >> On 10/05/2017 16:47, Thomas Huth wrote: >> >> So while we can delete pc-0.12, we can't delete associated features needed >> >> by pc-0.12, without complicating RHEL's ability to create its back-compat >> >> machine types. Downstream would have to un-delete the features. >> > >> > So I guess this is why Paolo said that pc-0.12 is still in "use" ... I >> > think removing pc-0.12, but not removing rombar=0 will cause confusion >> > in the upstream code base sooner or later, >> >> I agree. >> >> > so I guess we should rather >> > keep the pc-0.12 machine until we can get rid of it together with the >> > rombar code. We should still mark it as deprecated, of course. >> > >> >> I think tieing removal to major versions is a mistake, unless we're >> >> going to set a fixed timeframe for delivery of major versions. ie if >> >> we gaurantee that we'll ship a new major version every 18 months, that >> >> gives people a predictable lifetime. If we carry on inventing reasons >> >> for major versions at arbitrary points in time, it makes it difficult >> >> to have any reasonable forward planning. It is more users friendly if >> >> we can set a clear fixed timeframe for machine type lifecycle / eol >> > >> > IMHO we should have a new major release after we've reached a .9 minor >> > release, but so far it seems like I'm the only one with that wish... >> >> I actually like that, but then you've pretty much guaranteed that you >> _cannot_ remove anything deprecated until 4.0. You and Daniel aren't >> disagreeing as heavily as it seems, I think. > > I don't think we should tie removal of features to version numbers. IMHO > we should just increment the first major digit on a fixed time scale, > either once a year, or whenever we get past .9. > > For removal of features, IMHO, the only important thing is to give users > deprecation clear warning for 2-3 releases, and ensure feature detection > works well. As long as that is done, there shouldn't be any need to batch > them up for "major" releases. From libvirt POV, batching up removal to > major releases is not beneficial. Batching to major releases gives a very > inconsistent timeframe for removal too - somethign fdeprecated in .1 > release may live on for years, until the next $major.0, while something > deprecated in a .9 release can be killed in 4 months. I much prefer to > see a consistent deprecated for 2 releases / 8 months, then deleted > regardless of feature. I concur.
On 11.05.2017 17:10, Markus Armbruster wrote: > "Daniel P. Berrange" <berrange@redhat.com> writes: > >> On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote: >>> >>> >>> On 10/05/2017 16:47, Thomas Huth wrote: >>>>> So while we can delete pc-0.12, we can't delete associated features needed >>>>> by pc-0.12, without complicating RHEL's ability to create its back-compat >>>>> machine types. Downstream would have to un-delete the features. >>>> >>>> So I guess this is why Paolo said that pc-0.12 is still in "use" ... I >>>> think removing pc-0.12, but not removing rombar=0 will cause confusion >>>> in the upstream code base sooner or later, >>> >>> I agree. >>> >>>> so I guess we should rather >>>> keep the pc-0.12 machine until we can get rid of it together with the >>>> rombar code. We should still mark it as deprecated, of course. >>>> >>>>> I think tieing removal to major versions is a mistake, unless we're >>>>> going to set a fixed timeframe for delivery of major versions. ie if >>>>> we gaurantee that we'll ship a new major version every 18 months, that >>>>> gives people a predictable lifetime. If we carry on inventing reasons >>>>> for major versions at arbitrary points in time, it makes it difficult >>>>> to have any reasonable forward planning. It is more users friendly if >>>>> we can set a clear fixed timeframe for machine type lifecycle / eol >>>> >>>> IMHO we should have a new major release after we've reached a .9 minor >>>> release, but so far it seems like I'm the only one with that wish... >>> >>> I actually like that, but then you've pretty much guaranteed that you >>> _cannot_ remove anything deprecated until 4.0. You and Daniel aren't >>> disagreeing as heavily as it seems, I think. >> >> I don't think we should tie removal of features to version numbers. IMHO >> we should just increment the first major digit on a fixed time scale, >> either once a year, or whenever we get past .9. Once a year sounds too often for my personal taste, I really prefer the .9 way, but that's details... >> For removal of features, IMHO, the only important thing is to give users >> deprecation clear warning for 2-3 releases, and ensure feature detection >> works well. As long as that is done, there shouldn't be any need to batch >> them up for "major" releases. From libvirt POV, batching up removal to >> major releases is not beneficial. Batching to major releases gives a very >> inconsistent timeframe for removal too - somethign fdeprecated in .1 >> release may live on for years, until the next $major.0, while something >> deprecated in a .9 release can be killed in 4 months. I much prefer to >> see a consistent deprecated for 2 releases / 8 months, then deleted >> regardless of feature. > > I concur. Fine for me, too. My only additional point is that we *should* have major releases from time to time (ending up with something like QEMU 2.42 is just ugly), and that we *could* use them for additional spring-cleaning (not for the libvirt POV, but for the users POV). For example, we've got some parameters where we warn since QEMU 1.3 that it is deprecated and might go away soon. We now could use major releases to remind ourselves from time to time to look through the code for such deprecated interfaces and remove them with the next major version. (But removal would of course also be allowed at any other minor version release if the feature has been deprecated for at least two minor releases already). Thomas
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 9f102aa..16e2fb7 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -38,6 +38,7 @@ #include "sysemu/kvm.h" #include "hw/kvm/clock.h" #include "sysemu/sysemu.h" +#include "sysemu/qtest.h" #include "hw/sysbus.h" #include "sysemu/arch_init.h" #include "sysemu/block-backend.h" @@ -85,6 +86,12 @@ static void pc_init1(MachineState *machine, MemoryRegion *rom_memory; ram_addr_t lowmem; + if (!qtest_enabled() && !strncmp(MACHINE_CLASS(pcmc)->name, "pc-0.", 5)) { + error_report("Machine type '%s' is deprecated, " + "please use a newer type instead", + MACHINE_CLASS(pcmc)->name); + } + /* * Calculate ram split, for memory below and above 4G. It's a bit * complicated for backward compatibility reasons ...
We don't want to carry along old machine types forever. If we are able to remove the pc machines up to 0.13 one day for example, this would allow us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM BARs directly to low memory). So let's start with a deprecation message for the old 0.xx machine types so that the (hopefully) few users of these old systems start switching over to newer machine types instead. Signed-off-by: Thomas Huth <thuth@redhat.com> --- Note: I've decided to print the warning for all pc-0.* machine types, but that of course doesn't mean that we also have to remove them all at once when we decide to finally really remove some. We could then also start by removing 0.10 and 0.11 only, for example (since there should really be no users left for these), or only up to 0.13 (to be able to kill rombar=0), as discussed in the "Deprecating old machine types" mail thread recently. hw/i386/pc_piix.c | 7 +++++++ 1 file changed, 7 insertions(+)