Bug 818700 - Unable to re-provision a system with a bonded interface
Unable to re-provision a system with a bonded interface
Status: CLOSED CURRENTRELEASE
Product: Spacewalk
Classification: Community
Component: WebUI (Show other bugs)
1.8
All Linux
high Severity medium
: ---
: ---
Assigned To: Stephen Herr
Red Hat Satellite QA List
: FutureFeature
: 818698 (view as bug list)
Depends On: 589318
Blocks: space18
  Show dependency treegraph
 
Reported: 2012-05-03 14:42 EDT by Stephen Herr
Modified: 2012-11-01 12:19 EDT (History)
13 users (show)

See Also:
Fixed In Version: spacewalk-java-1.8.134-1
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 589318
Environment:
Last Closed: 2012-11-01 12:19:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen Herr 2012-05-03 14:42:37 EDT
+++ 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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.
Comment 1 Stephen Herr 2012-05-03 14:43:54 EDT
*** Bug 818698 has been marked as a duplicate of this bug. ***
Comment 2 Stephen Herr 2012-05-03 15:00:29 EDT
Committed to Spacewalk master: 19fcac6c97fdb0e4a0d6bbdf07513c04352297dc

There is now an option in the Advanced page to configure a network bond after the kickstart is finished.
Comment 3 Jan Pazdziora 2012-05-04 03:05:54 EDT
Moving back to ASSIGNED. The change broke java build:

https://koji.spacewalkproject.org/koji/getfile?taskID=103390&name=build.log

  [jasper2] May 4, 2012 2:34:24 AM org.apache.jasper.JspC processFile
  [jasper2] INFO: Built File: /WEB-INF/pages/kickstart/kickstarts.jsp
BUILD FAILED
/builddir/build/BUILD/spacewalk-java-1.8.61/build.xml:837: The following error occurred while executing this line:
/builddir/build/BUILD/spacewalk-java-1.8.61/build.xml:638: org.apache.jasper.JasperException: file:/builddir/build/BUILD/spacewalk-java-1.8.61/build/webapp/rhnjava/WEB-INF/pages/common/fragments/kickstart/schedule/post-network-options.jspf(30,16) The function arrayContains cannot be located with the specified prefix
Total time: 37 seconds

Can you please ivnestigate?
Comment 4 Tomas Lestach 2012-05-04 05:30:19 EDT
additional commit - make newly introduced rhn tag functions available ...

spacewalk.git: c46aadcf724f3b9e6526cbc20ee7005c73b15f54
Comment 5 Stephen Herr 2012-05-04 08:21:46 EDT
Oh, I accidentally made those changes to the generated version of that file that lives on my system, not the source file that gets checked into git. It should build now that Tomas has committed the fix.
Comment 6 Stephen Herr 2012-05-08 15:47:31 EDT
additional commit - make it so that you can't submit the kickstart form with broken bond info

spacewalk.git: bceaf8dee786c29829b2e171a41fae97ca102547
Comment 7 Stephen Herr 2012-05-09 09:01:53 EDT
An additional change need to be made to operate on Cobbler 2.2. Cobbler broke API compatibility in the minor version update, so that passing values for "bonding" and "bondingmaster" do not work and instead we must use "interfacetype" and "interfacemaster". Those new keys are not supported in Cobbler 2.0 however, so we would have to check which version of cobbler you have installed before we construct the argument list.
Comment 8 Milan Zazrivec 2012-05-10 08:38:31 EDT
Added support for cobbler v2.2: 7ab3858e7c25447507c53fd868df90e2f93e3620
Comment 9 Tomas Lestach 2012-05-11 05:47:48 EDT
checkstyle fixes ...

spacewalk.git: 711b464f93704df12e07e88c8b3db6add428e2e3
Comment 10 Stephen Herr 2012-08-08 15:31:17 EDT
Added support for static network bonds: 9c82179472ed771f436e882afac93edc68b6acf3
Comment 11 Stephen Herr 2012-08-24 16:27:00 EDT
This commit:

1) allows the user to set the gateway (requird for static network bonds)
2) allows the user to input ipv6 addresses without failing the is-ip-address check

Spacewalk master: 9bcb26dd83e7957f906d1348a3820fb91050b932
Comment 12 Jan Pazdziora 2012-10-30 15:23:43 EDT
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Comment 13 Jan Pazdziora 2012-11-01 12:19:00 EDT
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18

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