[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]