Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/