4:59 a.m.
Hi,
When enslaving an interface already enslaved by another
interface, the initscripts driver overtakes this enslaved
interface:
---------
ncftool> dumpxml bond0
<?xml version="1.0"?>
<interface type="bond" name="bond0">
<start mode="onboot"/>
<protocol family="ipv4">
<ip address="10.0.1.27" prefix="24"/>
</protocol>
<bond mode="active-backup">
<interface type="ethernet" name="eth2"/>
<interface type="ethernet" name="eth1"/>
</bond>
</interface>
ncftool> define interface/bridge.xml
Defined interface br0
ncftool> dumpxml br0
<?xml version="1.0"?>
<interface type="bridge" name="br0">
<start mode="onboot"/>
<mtu size="1500"/>
<protocol family="ipv4">
<dhcp/>
</protocol>
<bridge stp="off" delay="0.01">
<interface type="ethernet" name="eth1"/>
<interface type="ethernet" name="eth2"/>
</bridge>
</interface>
ncftool> dumpxml bond0
<?xml version="1.0"?>
<interface type="ethernet" name="bond0">
<start mode="onboot"/>
<protocol family="ipv4">
<ip address="10.0.1.27" prefix="24"/>
</protocol>
</interface>
ncftool>
---------
This breaks the XML schema defined by interface.rng, as there
should be "oneOrMore" interfaces enslaved by the bonding
interface.
The SUSE driver solves this by raising an error instead of
taking over enslaved interfaces:
---------
(.. same state as above)
ncftool> define interface/bridge.xml
error: unspecified error
error: interface eth1 slave of interface bond0, unable to continue
ncftool>
---------
Which direction should netcf have for this? My opinion is that
raising an error would be best, as this would allow for better
control over the enslaved interfaces. It would also be simpler
to avoid pitfalls as the bond0 state above.
Regards,
Jonas
--
Jonas Eriksson
Consultant at AS/EAB/FLJ/IL
Combitech AB
Älvsjö, Sweden
5:38 p.m.
On Mon, 2009-08-10 at 11:59 +0200, Jonas Eriksson wrote:
This breaks the XML schema defined by interface.rng, as there
should be "oneOrMore" interfaces enslaved by the bonding
interface.
Indeed, it does; I would only guarantee though that the XML you get from
dumpxml conforms to the schema if the config of your machine is
reasonable (with some hazy definition of reasonable)
If we want to avoid handing out broken XML, the dumpxml call should
probably result in an error like 'config of bond0 is so strange that I
can't even describe it', though even that might be more trouble than
it's worth, since the user can do their own validation and act on that.
You can get to a broken config (in the sense that dumpxml returns
non-conforming XML) by manually editing etc. config files, so we need to
handle that regardless.
The SUSE driver solves this by raising an error instead of
taking over enslaved interfaces:
---------
(.. same state as above)
ncftool> define interface/bridge.xml
error: unspecified error
error: interface eth1 slave of interface bond0, unable to continue
ncftool>
---------
Which direction should netcf have for this? My opinion is that
raising an error would be best, as this would allow for better
control over the enslaved interfaces. It would also be simpler
to avoid pitfalls as the bond0 state above.
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.
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 ?
David
10:03 a.m.
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, as enslaved interfaces are
listed in the bridge ifcfg-file as a whitespace separated list,
like so:
BRIDGE_PORTS="eth0 eth1"
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..
/Jonas
--
Jonas Eriksson
Consultant at AS/EAB/FLJ/IL
Combitech AB
Älvsjö, Sweden
5:09 p.m.
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
5383
days inactive
5385
days old
netcf-devel@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
David Lutterkort -
Jonas Eriksson