Bug 589318 - Unable to re-provision a system with a bonded interface
Summary: Unable to re-provision a system with a bonded interface
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Provisioning
Version: 530
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Stephen Herr
QA Contact: Martin Minar
URL:
Whiteboard:
: 689702 (view as bug list)
Depends On:
Blocks: sat-nextgen 818698 818700 sat550-blockers sat550-post-ga, sat550-test-blockers
TreeView+ depends on / blocked
 
Reported: 2010-05-05 20:18 UTC by Matthew Davis
Modified: 2018-11-29 21:59 UTC (History)
13 users (show)

Fixed In Version: spacewalk-java-1.7.54-97-sat cobbler-2.0.7-20
Doc Type: Enhancement
Doc Text:
Clone Of:
: 689702 818698 818700 (view as bug list)
Environment:
Last Closed: 2012-09-28 13:49:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.