|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap |
Date: | Tue, 27 Jul 2010 12:20:55 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Lightning/1.0b1 Thunderbird/3.0.5 |
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.14IIF 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/address@hidden/msg34944.html http://www.mail-archive.com/address@hidden/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
[Prev in Thread] | Current Thread | [Next in Thread] |