Re: Support for bonding and other advanced networking topics
Michael DeHaan wrote:
Just recently on IRC (join #cobbler on irc.freenode.net if you
aren't
there already) we were discussing whether we could use Cobbler's concept
of interfaces to describe more complicated setups and then use a Cobbler
snippet called in %post to set everything up.
We initially were thinking we could describe an interface like this:
cobbler system edit --name=foo --interface=1 --bond-group=asdf
--bond-opts="a=1 b=2 ..." --bond-alias="..."
cobbler system edit --name=foo --interface=2 --bond-group=asdf
--bond-opts="a=2 b=3 ..." --bond-alias="..."
The problem with this is that the bonding options are a property of the
resulting bonding interface asdf, and should be the same for both
interfaces. I'm not sure where we'd want to store those options.
And the %post section snippet (this would be new) would insure that
the
order of NICs booted is the same as those installed and everything is
configured. This would also set up things that Anaconda could not set up.
In the above example, eth1 and eth2 would be bonded as "asdf".
In the above proposal, I'd be willing to add the bits to Cobbler to
store the above kind of data, though I'd like for someone with more
networking skills to write the network configuration snippet.
I can do that. It probably wouldn't be much more than reusing bits of my
existing snippets. :)
We also talked a bit about IP "aliases" / VIPs and
bridging. I will
admit at this point that networking is /not/ my area, so what are
everyone's thoughts to the implementation of the above?
Hmm, this would be a fairly complex network topology for cobbler. I
think VIPs would be doable (just add a list of aliases to an interface),
but briding-setups are very specific to the user's situation.
What fields do we need to store to make this all possible to be
defined
at provisioning time and "just work"?
To eliminate the possibility of different bonding options specified on
two slaves of the same bond, we'd need a special bonding configuration
object (but this might be ugly). This bonding object would contain the
bonding options and the IP-configuration.
Per interface we need a field "bonding master", to link the interface to
this bonding object. We'd want a checkbox for hotplug as well. This
defaults to ON, but there's a bug with bonding + VLANs and hotplug.
(https://bugzilla.redhat.com/show_bug.cgi?id=442339)
Or we should just disable it by default.
Per interface we'd also need a list of virtual IPs.
Jasper