Bug 467954
| Summary: | initscripts upgrade from 8.45.17 to 8.45.19 breaks arp_ip_target | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Darcy Sherwood <darcy.sherwood> | ||||
| Component: | initscripts | Assignee: | initscripts Maintenance Team <initscripts-maint-list> | ||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE <qe-baseos-auto> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.2 | CC: | agospoda, casmith, ddumas, dkovalsk, harald, notting, pknirsch, syeghiay, tao | ||||
| Target Milestone: | rc | Keywords: | Regression | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-01-20 22:16:08 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Darcy Sherwood
2008-10-21 20:28:22 UTC
I've written a patch that will handle both the syntax with and without the +
I tested the change, and I was able to specify arp_ip_target both with and without the plus, as well as in lists of formats "arp_ip_target=192.168.1.1,192.168.1.2" and "arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2"
diff ifup-eth ifup-eth-fix
129c129
< if [ "${key}" = "arp_ip_target" ]; then
---
> if [ "${key}" = "arp_ip_target" -a "${value:0:1}" != "+" ]; then
Andy - did the wires get crossed on the way to the upstream docs somewhere? I don't have a big issue with this, but it may not get in for a while due to scheduling. Well, considering working configs broke in 5.2, marking as a regression. This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP. I think the documentation just didn't get updated. The intent was that we could specify: arp_ip_target=10.0.0.1,10.0.0.2,10.0.0.3 going foward instead of arp_ip_target=+10.0.0.1 arp_ip_target=+10.0.0.2 arp_ip_target=+10.0.0.3 in the BONDING_OPTS field in ifcfg-bondX. I'll test now to make sure that works. Ok, so it appears the bug we wanted to fix (getting rid of the '+') is working as expected. It seems we need to clarify the documentation in the kernel source tree so it is correct. That should not be too tough to manage -- I'll get cracking on it. I think that the issue is that the previous method, using the + signs, worked in 5.0 and 5.1 and are now broken in 5.2. So a user who got bonding working in 5.0 or 5.1 and updated their server to 5.2 would break their bonding configuration. It's my understanding that configuration files should not break between point releases the OS. It appears that the patch that Darcy supplied will allow either format to work, which will fix the config file regression as well as allowing for the new format to work, the best of both worlds. Created attachment 321205 [details]
bonding-doc-fix.patch
I agree, Calvin, it would be nice to support both.
Unfortunately the fact that the '+' was needed was a bug itself. I did not originally intend that we use it when I did the original initscripts patch for RHEL5.
When we discovered we needed the '+' in the configuration file, we went out and fixed it for 5.2 so the module options matched what was needed in ifcfg-bond0.
It's hard for me to call bugs that we fix 'regressions,' but I guess when customers rely on them that's how they feel.
Attached is the patch to the kernel documentation that should reflect our original intent.
Cloned this bug for comment #8 kernel-doc change. Thanks & regards, Phil We have code available to submit, so new package can go in as soon as this has acks. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0245.html |