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

[Daniel P. Berrange]

On Tue, Jul 27, 2010 at 12:20:55PM -0500, Anthony Liguori wrote:
> 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.

Not really practical - pretty much anything is a candidate because
we want to support as many of QEMU features as possible.

> >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.

This particular case of cache modes might have failed, but in the
broader picture it would have been more reliable. The vasty 
majority of the time, we only check whether a particular named
argument exists. This patch would make it very reliable todo so
because you could simply extract a single named field from the
JSON doc. The cases where we looked at the parameter options 
would have been improved a little, but still be potentially fragile.
Checking for version number would also be improved. So overall 
while obviously not perfect, it would be significantly better than
the solution today and using an approach that isn't a complete
throwaway solution.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|