On Tue, Jul 27, 2010 at 11:38:04AM -0500, Anthony Liguori wrote: > On 07/27/2010 11:09 AM, Daniel P. Berrange wrote: > >On Tue, Jul 27, 2010 at 10:55:03AM -0500, Anthony Liguori wrote: > > > >>Today libvirt parses -help output to attempt to enumerate capabilities. > >>This > >>is very broken and has led to multiple failures. Since libvirt is an > >>important > >>management interface to QEMU, we need to do a better job giving them the > >>ability > >>to detect what a QEMU executable supports. Right now, we keep fixing up > >>help > >>output to appease it's parsing code but this is undesirable. > >> > >>The Right Solution is to introduce a robust capabilities advertisement > >>that > >>enumerates every feature we have. As with most Right Solutions, we don't > >>have > >>mergable code today and it's unclear that we'll get there by the next > >>release. > >> > >>This patch introduces an incremental solution of just spitting out the > >>handful > >>of capabilities libvirt is probing for today. This interface will need to > >>remain forever but can stop being updated once we have a Right Solution. > >> > >This isn't really workable because it only encodes the subset of things > >that libvirt currently looks for. If someone comes along with a libvirt > >patch for a new features that is already supported by QEMU, but isn't > >in this simple output, we're stuck. > > 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. 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. > > 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@xxxxxxxxxx/msg34944.html http://www.mail-archive.com/qemu-devel@xxxxxxxxxx/msg34960.html 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 -- |: 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list