[netcf-devel] Enslaving already enslaved interfaces

David Lutterkort lutter at redhat.com
Wed Aug 12 22:09:42 UTC 2009


On Tue, 2009-08-11 at 17:03 +0200, Jonas Eriksson wrote:
> On Mon, Aug 10, 2009 at 10:38:27PM +0000 David Lutterkort wrote:
> > My concern is that by not allowing to break configs we can easily end up
> > in a place where getting a machine into a known reasonable state becomes
> > impossible. For example, I'd want management tools to be able to
> > discover all ethernet devices on a machine, configure each of them as a
> > standalone ethernet interface with DHCP, and possibly delete all other
> > bridge/bond interfaces without regard of what might break in the
> > process.
> 
> I see your point here and agree with your reasoning. It will be
> quite a task to implement it on SUSE,

I am not sure what 'it' refers to in the above - if you mean the 'take
over a box and reconfigure all ethernet interfaces', that's not
something netcf would do. It's something that users of/apps on top of
netcf would do. Besides netcf, they'd need a list of Ethernet interfaces
on the machine, which they need to obtain separately.

>  as enslaved interfaces are
> listed in the bridge ifcfg-file as a whitespace separated list,
> like so:
> BRIDGE_PORTS="eth0 eth1"

Can your driver handle that already ? Breaking BRIDGE_PORTS into its
components might be something that's done more easily in the lens than
in the stylesheet ...

> > At the same time, it would be good to add detailed diagnostics like the
> > ones you have above - should we think about a 'ncf_check' call that
> > looks at an XML interface spec and returns warnings like what you have
> > above for the SuSe driver ?
> 
> Some kind of sanity check would be good in any case. Another
> option would be to add a force-flag, to allow things like
> overtaking enslaved interfaces. I would prefer a force-flag as
> for example overtaking already enslaved interfaces is probably
> something that the user would not want to do. Plus, my experience
> with check commands is that people don't use them..

Since the main audience for netcf is applications, I'd assume that such
a call would see more use. In any event, we'd have the behavior that
ncf_define by itself forces and 'if (ncf_check()) ncf_define' would not
force a change.

David




More information about the netcf-devel mailing list