On Thu, Jun 18, 2009 at 10:50:10PM +0000, David Lutterkort wrote:
> On Thu, 2009-06-18 at 20:48 +0100, Daniel P. Berrange wrote:
> > On Thu, Jun 18, 2009 at 07:05:29PM +0100, Daniel P. Berrange wrote:
> > >
> > > I think this is a really unpleasant format to deal with. IMHO there should
> > > not be nesting for <bridge>/<bond> tags. They should just refer to their
> > > slave device by name. So that last example would be better shown as a set
> > > of independant intefaces
> >
> > Rationalizing the reason why I don't like this format. The relationship of
> > NICs essentially forms a DAG. This format is attempting to define a tree
> > from the POV of a single leaf node.
>
> They do form a tree, with the exception of VLAN's: every other instance
> of an interface can be contained/used by at most one other interface. We
> need to treat VLAN's a little special, and allow them to reference
> external (to the XML) interfaces.
Trying to digest that long discussion maybe there is a solution:
- Dan thin a pure tree representation is not sufficient to express
all relationships between interfaces
- Dave would like to preserve the ability run the checks on a single
XML instance
I think both can be accomodated but that requires a slight change of
API, i.e. the XML will be able to define a set of interfaces. Basically
we could do
<interfaces>
<!-- define the set of physical interfaces -->
<interface ... name="eth0" ..>
....
</interface>
<interface name="eth1" ...>
....
</interface>
...
<!-- then define bonding, bridging and vlans -->
<bond mode="active-backup">
<source name="eth0"/>
<source name="eth1"/>
</bond>
<bridge name="br0">
<mtu size="1500"/>
<dhcp/>
<source name="eth3"/>
</bridge>
<vlan>
....
</vlan>
</interfaces>
I think this solves the expressiveness issues raised by Dan, I think
we can still do the checking at validation time (note that I moved name
as attributes which makes it nearly trivial using ID/IDREF in DTD/RNG or
even XSD)
I think this makes way cleaner the definition of interface for example
in a bridge situation, the underlying ethernet really ought to be a
first class citizen not have it's definition pushed down inside the
bridge just because it's currently used to that.
The <interfaces> description would still internally be chunked out
so that you could invoke the API to get a part of the whole set, you
may just get an <interface> <bridge>, <bond> or <vlan>, which could
still be used to modify parameters.
I also feel this may avoid races in definitions where we want a bunch
of separate but related interfaces needed for a service, and doing it
in one API call may allow to do thing in a more atomic fashion.
The main problem is that it departs seriously from the existing netcf
format and API design, and the XSLT processing may be a bit harder
(but not that much I expect), I can write a schemas for this with updates
based on feedback for the previous version .
Opinions ?
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list