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 > [email protected] > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
