On Thu, Apr 10, 2008 at 09:38:36PM +0100, John Levon wrote:
On Thu, Apr 10, 2008 at 04:19:47PM -0400, Cole Robinson wrote:
> > 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"?
> >
>
> To quote Eunice:
>
> > I don't think the first option (to change the LDoms Manager XML
> > format to be based on the libvirt XML format) is a feasible one
> > since LDoms has been released public and some tools/applications
> > are already based on the LDom Manager's XML interfaces.
>
> How can that be interpreted as anything but 'final'? An RFC is not
> about implementation details, it should be about the big picture.
> Already shipping a supported product based on an XML format that
> was not discussed upstream prior is about as final as it gets, IMO.
All Eunice is saying (pretty clearly IMO) is that the ldoms XML format
is used by an entire set of software already *unrelated to libvirt*.
That is Sun can't change their 'ldm' binary etc. to use libvirt's
format. I wouldn't be surprised if it pre-dates the libvirt project
altogether.
Ok, so we've got crossed-wires here fortunately & there is no serious
problem.
When Eunice refer to apps using the XML, I interpreted that to mean
apps using libvirt LDoms, whereas in fact it meant apps using the LDoms
tools.
We clearly won't expect the native LDoms tools to change. So the way forward
for the LDoms libvirt driver is to define a mapping between the two XML
formats and have the LDoms driver internally do the conversion either
manually, or using a XSL transform.
Dan.
--
|: Red Hat, Engineering, Boston -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|