Re: [PATCH 8/9] ifcfg: Ignore higher level configs for bonding slaves

[Dan Williams <dcbw redhat com>]

On Tue, 2011-10-11 at 16:23 +0200, Thomas Graf wrote:
> On Tue, 2011-10-11 at 08:26 -0500, Dan Williams wrote:
> > On Fri, 2011-09-23 at 14:52 +0200, Thomas Graf wrote:
> > > Functionatlity is implemented on NMSettingConnection level in case
> > > other device types require this as well.
> > > 
> > > Adds a dummy ip4_config when high level config is disabled. This is
> > > required in order not to fall back to using DHCP.
> > 
> > I'm not 100% sold on this; is there a reason we couldn't just set the IP
> > configuration to disabled here?  I feel like this is something we can
> > detect programmatically so it's perhaps not something we should put into
> > the setting API itself.
> > 
> > What we could do here instead is override the IP config stuff in the
> > Ethernet device class and check if the connection being activated is a
> > bond slave.  We already have to do that (later) for activating the
> > master connection when the slave is activated.
> 
> I am very much open to a better implementation regarding this and I
> think your proposal is much cleaner.
> 
> To make sure I understood you properly: You propose to replace any
> existing IP config with a "IP disabled"-config before entering stage1
> while activating a bonding slave. Right?

Well, I'd assume the bond's IPv4 config is already disabled?  Or do we
allow separate IP configs on the bond slaves in addition to the master?
I've heard of this for bridging but not necessarily for bonding.

But anyway, there are two choices if the bond has an IPv4 config: either
that's invalid and we don't let the connection pass validation (in
libnm-util/nm-setting-ip4-config.c's verify() method), or having this is
valid and we should deal with it now or in the future.

> The only problem I see with this method is that we expose a IP config
> to the UI which is never used. A user may be tempted to modify a bonding
> slave IP config only to see it being overwritten when the connection
> is activated. But I guess we'd have to add a special case anyway to not
> allow modifying the IP config of connections which are configured as
> bonding or bridging slaves.

Right.  If the config is invalid and we don't allow this, then we make
sure the connection fails validation in verify() in
nm-setting-ip4-config.c, and then we make sure to document this so that
the UI knows it's not possible.  This is the same thing we do for PPP,
where 99% of the time as a client you cannot set the IP address, because
it's provided for you by upstream and it would be pointless to set one
of your own.  Same thing for bonding; the UI should just disable the
options.

Dan