Re: [libvirt] [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap
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