[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Thu, 2009-06-18 at 19:05 +0100, Daniel P. Berrange wrote:
> > Similarly, a bond enslaved to a bridge, together with a vlan on that
> > bond also enslaved to the bridge would look like
> > 
> >         <interface type="bridge" startmode="onboot">
> >           <name>br0</name>
> >           ...
> >           <bridge stp="off">
> >             <interface type="bond">
> >               <name>bond0</name>
> >               <bond mode="active-backup">
> >                 <interface type="ethernet">
> >                   <name>eth1</name>
> >                 </interface>
> >                 <interface type="ethernet">
> >                   <name>eth0</name>
> >                 </interface>
> >               </bond>
> >             </interface>
> >             <interface type="vlan" device="bond0" tag="42"/>
> >           </bridge>
> >         </interface>
> 
> I think this is a really unpleasant format to deal with.

There's two reasons why I prefer that rather than splitting everything
into multiple standalone <interface> tags:

     1. When as many components of the overall interface/connection are
        in one place, more validation can be done in RelaxNG, i.e.
        statically
     2. Because of this, it is easier for application writers to test
        and validate the XML they generate - most issues can be caught
        by validating against the RelaxNG, and fewer issues depend on
        doing things in the right order (for example, with the nested
        format, you cna never get into a situation where you enslave an
        undefined bond into a bridge)

I assume what you find unpleasant is that when you generate the XML you
need to embed one interface in another, though that seems to me mostly
an issue in what order you do your sprintf's.

> IMHO there should not be  nesting for <bridge>/<bond> tags.

For <bond>, there's nothing to worry about, since all you can add to a
bond are physical interfaces (since all the possible nesting gets
confusing, I drew a little picture)

vlans can't contain their underlying device, since there can be many
vlan's used in multiple interfaces for a device. This is the one place
in the format I suggested where we need an external reference check: we
need to make sure that the interface underlying the vlan is already
configured. 

Bridges, of course, are hopeless, since they are omnivorous. But again,
with the nested format, all sanity checking can happen in RelaxNG,
except for the referential integrity of vlan's.

>  They should just refer to their
> slave device by name. So that last example would be better shown as a set
> of independant intefaces
> 
>          <interface type='bond'>
>            <name>bond0</name>
>            <bond mode="active-backup">
>              <interface name='eth0'/>
>              <interface name='eth1'/>
>            </bond>
>          </interface>

This requires that you check that the interfaces named there are
physical NIC's at runtime.

>          <interface type='vlan'>
>            <name>bond0.42</name>
>            <vlan tag='42'>
>             <interface name='bond0'>
>            </bridge>
>          </interface>

I don't think there's a good case for setting the name of a VLAN
explicitly. vconfig let's you choose from one of four naming modes, but
I am not even sure it's worth exposing those in the XML.

>          <interface type="bridge" startmode="onboot">
>            <name>br0</name>
>            ...
>            <bridge stp="off">
>              <interface name="bond0.42"/>
>            </bridge>
>          <interface>

At this point, you need to check that bond0.42 is defined, without any
address setup.

> If you added more vlans, then they just appear as more interfaces at
> the top level

I would really like to stick to a model where toplevel interfaces are
the ones that aren't contained in other interface definitions anymore.

David

Attachment: nesting.png
Description: PNG image


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]