Jasper Capel wrote:
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.
How about with the first interface in the bonded set?
> 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.
Yeah, we could just not do them. Virt-bridging is already dealt with by
libvirt.
> 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.
Given the above "cobbler system edit" syntax can you sketch out what you
think this might look like?
For things that are proprieties of the bonded set, I'd say storing them
with the first in the set wouldn't be too hideous.
Otherwise we could just do it correctly and modify the bonding rules on
top of the interfaces already there, though this ends up complicating
the webapp just a bit.
A crazy way to do it might be
cobbler system edit --name=foo --bonds="alpha=0,1:options
beta=2,3:options" or something a bit more complex, though that is less
editable and probably not as clean.
Jasper
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler