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