Bug 763418 (GLUSTER-1686)

Summary: Replacing the Ethernet card causes the named mapping to change causing a service failure
Product: [Retired] GlusterSP Reporter: Kevin Brooks <brooks>
Component: coreAssignee: Timothy Asir <timothyasir>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: urgent    
Version: 3.0.5CC: platform, shireesh
Target Milestone: 3.1.2   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Kevin Brooks 2010-09-23 18:18:49 UTC
After replacing an interface card you have to modify /etc/udev/rules.d/70-persistent-net.rules and /etc/sysconfig/network-scripts/ifcfg-eth* to get the mapping setup correctly.  Depending on what you replaced you could be locked out of the system since there is no standard console access to the server provided.

Comment 1 Kevin Brooks 2010-09-23 19:33:32 UTC
An additional bug exists that relates to this behavior.  The web based GUI retains the incorrect mapped interfaces even after you correct them in udev and sysconfig.  For example, I replaced 2 PCI Ethernet cards which caused mappings for eth4 and eth5 to get created.  I remapped and removed those entiries in udev and sysconfig files but the eth4 and eth5 mappings remain.  I realize you guys are just using the rhb python libs to derive this information, but it's still a problem none the less.  To remove these bogus interfaces I had to use the NetworkManager telling it not to manage them, and then deleting them from it's list of interfaces.  I'm sure there's probably a way to do it via the command line, but I couldn't find one.