Red Hat Bugzilla – Bug 818700
Unable to re-provision a system with a bonded interface
Last modified: 2012-11-01 12:19:00 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)
Steps to Reproduce:
1. Select a registered system to provision
2. Goto Provisioning -> Select the proper profile -> Advanced Configuration -> Select interface
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 email@example.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 firstname.lastname@example.org 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.
--- Additional comment from email@example.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 firstname.lastname@example.org on 2010-05-20 05:52:41 EDT ---
Event posted on 20-05-2010 10:52am BST by zakhtar
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
I'm sure that you are already aware of the page, but this is how to use
Cobbler to configure bonding:
It should be possible to add a web-front end for these options to
Satellite, given how many of the other 'standard' options effectively
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
--- Additional comment from email@example.com on 2010-08-11 11:42:33 EDT ---
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.
--- Additional comment from firstname.lastname@example.org 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?
--- Additional comment from email@example.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.
*** Bug 818698 has been marked as a duplicate of this bug. ***
Committed to Spacewalk master: 19fcac6c97fdb0e4a0d6bbdf07513c04352297dc
There is now an option in the Advanced page to configure a network bond after the kickstart is finished.
Moving back to ASSIGNED. The change broke java build:
[jasper2] May 4, 2012 2:34:24 AM org.apache.jasper.JspC processFile
[jasper2] INFO: Built File: /WEB-INF/pages/kickstart/kickstarts.jsp
/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?
additional commit - make newly introduced rhn tag functions available ...
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.
additional commit - make it so that you can't submit the kickstart form with broken bond info
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.
Added support for cobbler v2.2: 7ab3858e7c25447507c53fd868df90e2f93e3620
checkstyle fixes ...
Added support for static network bonds: 9c82179472ed771f436e882afac93edc68b6acf3
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
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18