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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list