Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Thomas Huth <thuth@redhat.com>]

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