|Summary:||Unable to re-provision a system with a bonded interface|
|Product:||Red Hat Satellite 5||Reporter:||Matthew Davis <mdavis>|
|Component:||Provisioning||Assignee:||Stephen Herr <sherr>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Martin Minar <mminar>|
|Version:||530||CC:||cherguet, cperry, gbarros, juergen.schilp, mkoci, mkorbel, mminar, mosvald, mzazrivec, pmutha, rdassen, stanislav.polasek, xdmoon|
|Fixed In Version:||spacewalk-java-1.7.54-97-sat cobbler-2.0.7-20||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|:||689702 818698 818700 (view as bug list)||Environment:|
|Last Closed:||2012-09-28 13:49:18 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||672946, 818698, 818700, 818987, 819024|
Description Matthew Davis 2010-05-05 20:18:21 UTC
Description of problem: If a system is currently operating with a bonded interface (ie bond0 with eth0/eth1 as slaves), it is not possible to re-provision that machine. Version-Release number of selected component (if applicable): spacewalk-backend-0.5.28-34 (if you need more rpm versions, lmk) How reproducible: Everytime Steps to Reproduce: 1. Select a registered system to provision 2. Goto Provisioning -> Select the proper profile -> Advanced Configuration -> Select interface 3. Actual results: No bond0 Expected results: Select bond0 Additional info: There is a catch-22 situation here. anaconda does not support bonded interfaces per bug 240580. So even if the satellite were to grab the proper bond information, anaconda won't/can't bring up the bonded interface.
Comment 1 Matthew Davis 2010-05-05 20:20:08 UTC
I've only tested this with static networking, but I see no reason this will work with dhcp. Kickstart should still fail.
Comment 5 Justin Sherrill 2010-08-11 15:42:33 UTC
Hrm, So if a system has a bond, satellite will see the bond and the interfaces, but we don't know for 100% certainty which eth devices belong in the bond. I'm not sure how to get around this. We could try to guess, but that doesn't seem quite right. Ideas? -Justin
Comment 6 Justin Sherrill 2010-08-11 16:18:17 UTC
Another option would be on the provisioning page (where you schedule a re-provisioning), add an option for bonding, where the user can select which interfaces they want bonded (with eth0 and eth1 selected by default). We'd also probably put an option for 'bonding options' and put a sane default. Does that sound reasonable? -Justin
Comment 7 Matthew Davis 2010-08-11 18:13:46 UTC
I believe a combination of the two ideas would work. I don't think we should guess. The user should select the interface (ethX) to boot & install from (ksdevice). Then, if they wish to configure bonding, give them an option to select the bonded devices, and fill in a box for the bond options. Examples provided above the box, but not filled in.
Comment 9 Paresh Mutha 2011-03-23 09:38:38 UTC
*** Bug 689702 has been marked as a duplicate of this bug. ***
Comment 24 Stephen Herr 2012-05-03 19:16:54 UTC
I have a set of changes pending that I believe will resolve this issue. The changes are available in the latest Spacewalk master code for review. Essentially there is a new section in the "Advanced" page of kickstart configurations in the web UI. This new section allows users to set up bonded network interfaces on the post-kickstart system, whether or not they have bonded interfaces on the pre-kickstart system. Bond name, slave NICs, and bond options are all configurable. If Satellite detects that the pre-kickstart system has a bonded interface, it attempts to autofill the fields with appropriate defaults to re-create the bond post-kickstart. The user can still of course change whatever he would like. Creating a bonded network interface post-kickstart is always off by default. I believe this change satisfies the customer's needs / wants. If I have missed something let me know.