[netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces

[Daniel Veillard]

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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/