+++ This bug was initially created as a clone of Bug #589318 +++

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.

--- Additional comment from mdavis on 2010-05-05 16:20:08 EDT ---

I've only tested this with static networking, but I see no reason this will work with dhcp.  Kickstart should still fail.

--- Additional comment from cperry on 2010-05-12 09:42:53 EDT ---

I don't know how we would fix this Matt if Anaconda itself does not support it. What do you expect us to do here? :) 

Or - what do you want us to fix. I'd expect that maybe what your getting at is something like - if bonded, allow you to select say eth0 - ks through it and then post installation re-create the bonded interface. This is boarder line RFE. So please help us understand what you would like us to address. 

Thanks,
Cliff

--- Additional comment from mdavis on 2010-05-12 10:48:01 EDT ---

Yes, that's kinda what I had in mind too.  Cobbler does have the ability to re-create the bond if the system profile has it defined ( See https://fedorahosted.org/cobbler/wiki/AdvancedNetworking ).  So the ideal solution would be

- select bonded interface from the dropdown
- pull in the networking information, and kick from one of the devices found in the bond (since anaconda won't do bonding)..  there is the assumption that if a device is found in the bond, it should be accessible using the same network config as the bond, which I believe is a safe assumption.
- configure cobbler to kick and add the bonded network devices (why re-invent the wheel)

The key thing to keep in mind, to the user, having a bonded interface shouldn't be a hindrance.  And current workflow should be the same for a bonded interface as a regular interface.

--- Additional comment from tao on 2010-05-20 05:52:41 EDT ---

Event posted on 20-05-2010 10:52am BST by zakhtar


Hello,

The customer has updated the case and the information that they provided
appears to be a very useful insight (some covered already). I have
provided it in the IT and BZ in case for your review:

------------------------------------------------------------------------------
 
I am aware that Anaconda is limited in the 'advanced' networking
configurations it supports and it is disappointing that it won't be
updated. However, Cobbler supports configuring fully bonded network
interfaces and is already heavily used in Satellite (sometimes to the
point of getting in the way!).  In fact, when we were trying to find a
workaround, I did experiment with modifying the Satellite-generated
Cobbler profiles of a few clients from the command line to configure
bonded interfaces.  It worked (as long as I started the kickstart using
'koan' on the client), but it was deemed to be un-workable for our
environment, mainly due to the number of systems we have and partly due to
do our administration set up (we need as much as possible to be web
driven).  
 
I'm sure that you are already aware of the page, but this is how to use
Cobbler to configure bonding: 
 
https://fedorahosted.org/cobbler/wiki/AdvancedNetworking 
 
It should be possible to add a web-front end for these options to
Satellite, given how many of the other 'standard' options effectively
have one. 
 
A simpler issue to fix, however, would be just to get Satellite to allow
you to select any physical network device to kickstart with, regardless of
whether it is currently configured with an IP address or not (which seems
to be what determines if it is presented in the 'Advanced Kickstart
Options' page).  We are used to having to configure bonding in the %post
section as Anaconda has lacked that feature for so long.  The main problem
with Satellite is it's assumption that the currently configured network
interface is the only one the system has...

------------------------------------------------------------------------------




This event sent from IssueTracker by zakhtar 
 issue 849823

--- Additional comment from jsherril on 2010-08-11 11:42:33 EDT ---

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

--- Additional comment from jsherril on 2010-08-11 12:18:17 EDT ---

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

--- Additional comment from mdavis on 2010-08-11 14:13:46 EDT ---

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.