On Wed, Jun 25, 2014 at 08:14:12AM +0200, Peter Krempa wrote: > On 06/24/14 21:34, Eric Blake wrote: > > On 06/24/2014 03:39 AM, Daniel P. Berrange wrote: > > > >>> > >>> We also have a <features> subelement of <guest> in the <capabilities> > >>> XML which is used for a similar thing although it doesn't support a > >>> per-machine-type output, only per-binary capabilities. Should we add > >>> this more granular approach and abandon the old one? > >> > >> Yes, we should stop adding stuff related to the guest to the main > >> <capabilities> XML since it doesn't scale. > > > > Oh phooey - I just proposed yet another feature there: > > https://www.redhat.com/archives/libvir-list/2014-June/msg01097.html > > > > I'd like to turn on a witness for active commit support in the same > > release as we turn on the qemu implementation (and I'm hoping it still > > makes libvirt 1.2.6 - we haven't frozen yet, but it's near the end of > > the month, and we're still waiting on some patches to make it into > > qemu.git). If <features> is not the right place, then where should I > > advertise it? > > > > Well, currently in the upstream state <features> is the only place where > we can do it until Michal's new API gets in. We might need to add that > particular feature there if this series doesn't make it, while active > commit does. Yeah, one more feature in existing capabilities XML isn't going to kill us. Might as well stick with what you have until we actually have the new API merged. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list