Re: [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/27/2010 12:00 PM, Daniel P. Berrange wrote:
>> Yup.  You'll need to decide up front if you want to probe for a feature
>> when it's introduced and have something added to capabilities.
>>
>> This is simple though.  A few weeks before 0.14 is released, go through
>> the change log, and anything that looks interesting, add a cap flag.
>>      
> That doesn't work for features which already exist in QEMU which are
> not yet supported in libvirt. eg consider QEMU 0.13 is released, and
> then we want to add a new feature to libvirt a month later.

Right.  So sit down and look at the 0.13 changelog and if there's any 
features that you think you might want to support at some point in time, 
add a capability.

>   We can't
> simply add something extra to the capabilities because QEMU is already
> released at this point. There is a large amount of stuff that falls
> into this category.
>    

It doesn't have to be perfect, it just has to be good enough.

>>>   Adding a one-off special case for
>>> the 0.13 release that we know will be obsolete in 0.14
>>>        
>> IIF capabilities gets merged by 0.14.  I'd certainly like it to, but I'd
>> prefer to hedge my bets.
>>
>> Here are the possible things we can do:
>>
>> 1) merge -libvirt-caps as an intermediate solution, stop caring about
>> -help changes, when full caps are introduced, stop updating -libvirt-caps
>>
>> 2) don't merge -libvirt-caps, stop caring about -help changes, put
>> everything on getting full caps merged by 0.14
>>
>> 3) don't merge -libvirt-caps, care about making -help changes, use -help
>> as the caps mechanism until full caps get merged
>>
>> We can't do (3).  I'm going to revert the -help changes for 0.13 so that
>> old versions of libvirt work but not for master.
>>
>> (2) makes me pretty uncomfortable because it implies either (a) delay
>> 0.14 until full caps are ready (b) ship 0.14 such that libvirt is
>> totally broken.
>>
>> (1) isn't ideal, I'll freely admit, but it's a workable intermediate
>> solution.
>>      
> It offers significantly less information that the existing -help
> data, so I don't think it is workable as a replacement. We'd get
> into the bad situation where we could support a feature in 0.12
> but not in 0.13, unless we went back to using -help output again.
>
> If we're going for a short term hack, then how about a combination
> of
>
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg34944.html
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg34960.html
>    

Would have failed in exactly the same way that the current -help parsing 
fails.  The description of an argument in the help text is not a 
capabilities string.

Regards,

Anthony Liguori

> so that we have the same level of information as '-help' but in
> a more stable&  machine friendly format.
>
> As we add further patches for capabilities, we'll migrate
> away from the 'query-help' data and into the other capabilities
> commands "query-netdevtypes" 'query-config' etc.
>
> Daniel
>