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

[David Lutterkort]

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.

> An application using this, still retains the
> flexibility to display the information in the structure that is most
> suitable for its needs, be it paths from the POV of a leaf, paths from 
> the POV of a root, the entire tree in one, or flat lists, or some other
> hybrid.

I don't think that what an application can display is hindered by any of
the formats we've been discussing. To me, the overriding concerns are
(a) exposing as much as possible for static checks in the RelaxNG
grammar and (b) avoid writing the representation in a way that causes
undue headaches in some of the backends we'll eventually need, by
assuming e.g. we can write out the config for a partial interface.

> >          <interface type='bond'>
> >            <name>bond0</name>
> >            <bond mode="active-backup">
> >              <interface name='eth0'/>
> >              <interface name='eth1'/>
> >            </bond>
> >          </interface>
> 
> So this shows children, while the XML for the physical interface could
> show the inverse.

The importnat thing is that it has parent/child relations going both
ways in one place, and therefore is much less likely to cause headache,
no matter whether the config backend writes its config files in a more
child->parent oriented manner (like initscripts) or in a parent->child
oriented manner (like Debian[1])

>         <interface type='physical'>
>            <name>eth0</name>
>            <master>
>              <interface name='bond0'/>
>            </master>
>         </interface>

No; we need to come up with _one_ way to express 'bond0 consists of eth0
and eth1', not multiple ways. There's no value in that, only headache;
enterprising souls are free to create alternate views of the XML with
their favorite XSL stylesheet - something tha the nested representation
makes easier.

> The API contract might wish to specify the order for defining new
> interfaces, eg whether to require the bond0 to be defined first
> and then physical interfaces added, whether physical members must
> be defined first & then the bond, or whether creation of the bon0
> automatically implies that interfaces for eth0/eth1 appear in the
> list.

If you do that, you require that netcf stores some data in some
lookaside location - with your last example above, on Debian, nothing
can be written to /etc/network/interfaces, until the actual bond device
is defined. Also, what would it mean if bond0 already exists (say,
bonding eth1 and eth2) and an interface is defined with the above XML
snippet ? Do eth1 and eth2 stay in the bond ? If so, how do you get rid
of eth2 in the bond ?

David

[1] http://wiki.debian.org/Bonding