On Thu, Apr 10, 2008 at 08:33:28PM +0100, Daniel P. Berrange wrote: > > > If the LDoms code is to be merged into libvirt, IMHO, it has to > > > be 100% compliant with the defined libvirt XML format. > > > > Or extend it, surely? > > Well there are two separate scenarios here. Some of the elements in the > the LDoms XML are expressing concepts for which there is no existing > libvirt XML format defined. If they are suitably generic that they can > be applied to other non-LDoms drivers then we can add them to the official > libvirt XML format, otherwise they'll have to be changed to be suitably > flexible. Other XML elements in the LDoms XML are representing things > that are already represented in libvirt, but using a different format. > > The key is that we need an XML format that has consistent representation > across all drivers. IMHO, the LDoms format as illustrated earlier in this > thread is very far away from being suitable for inclusion in libvirt. Fine. I don't disagree with any of this. > > (I know I've whined before but it would be awfully nice to have some-one > > step up and update the schema: then it would be possible to insist all > > such changes update the schema too.) > > Yes, but that doesn't excuse developing these extensions in private and then > just dumping them on the list as a final solution. That's hardly fair. There's a big 'RFC' in the subject and Ryan explicitly said they weren't ready. Eunice has been responding to all your comments. Who's been talking of "final solutions"? > The only practical way to develop extensions to the XML format is to > have upfront discussions on the proposal prior to implementation so > all stakeholder have the chance to discuss the propsals. I'm not sure I agree with this. Talk is pretty cheap, whereas prototypes are actually useful. These patches are a prototype implementation: they've been sent out for discussion, and that's happening. I'm really not sure where the issue is. regards, john -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list