Bug 744873

Summary: [NetApp 6.3 FEAT] Anaconda should configure multipath.conf as per dm-multipath's built-in defaults
Product: Red Hat Enterprise Linux 6 Reporter: Rajashekhar M A <rajashekhar.a>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED NOTABUG QA Contact: Release Test Team <release-test-team>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.3CC: bmarzins, coughlan, ctatman, ichute, marting, revers, xdl-redhat-bugzilla
Target Milestone: alphaKeywords: FutureFeature, Reopened
Target Release: 6.3   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-11 13:14:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 720377    

Description Rajashekhar M A 2011-10-10 18:24:29 UTC
This is a feature request to make the necessary changes to anaconda so that multipath.conf is configured as per the default values during installation. 

For example, anaconda enables user_friendly_names option by default during installation. That is, the user_friendly_names is configured as "yes", though the default multipath.conf value is "no" as documented in http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/DM_Multipath/config_file_defaults.html.

It would be great if anaconda sticks to the defaults of dm-multipath. The parameters and their defaults are available in /usr/share/doc/device-mapper-multipath-<version>/multipath.conf.defaults file on an installed host.

Comment 2 David Cantrell 2011-10-10 19:28:31 UTC
The user_friendly_names=yes usage in anaconda is deliberate.  Feedback from different users indicated the desire to see 'mpatha' rather than '3600a0b800067fabc000067694d23fe6e' in the user interface.  Most users requested a multitude of different ways to be able to determine what devices they should be using, as the user_friendly_names were really just easier on the eyes, but not indicative of what device was what.  This is why you can specify devices using the names exposed in /dev/disk and it's why in the user interface, we expose various pieces of identifying information about volumes (manufacturer, vendor, serial, size, and so on).

Comment 3 David Cantrell 2011-10-10 19:31:46 UTC
Also, it looks like the default now in device-mapper-multipath and the documentation link you provided is for user_friendly_names=yes.

Comment 4 Rajashekhar M A 2011-10-11 08:04:59 UTC
The document clearly mentions the default value for the parameter is "no". See "Table 4.1 - Multipath Configuration Defaults". Also the file multipath.conf.defaults on a RHEL6.2 Beta installation has the following:

# cat /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf.defaults
# These are the compiled in default settings.  They will be used unless you
# overwrite these values in your config file.

#defaults {
#       udev_dir                /dev
#       polling_interval        5
#       path_selector           "round-robin 0"
#       path_grouping_policy    failover
#       getuid_callout          "/lib/udev/scsi_id --whitelisted --device=/dev/%n"
#       prio                    const
#       path_checker            directio
#       rr_min_io               1000
#       rr_weight               uniform
#       failback                manual
#       no_path_retry           fail
#       user_friendly_names     no
#}
#
...

I have opened this bug as per the suggestion in the following comment and also that we believe it's best to stick to the individual modules' defaults instead of overriding them:
https://bugzilla.redhat.com/show_bug.cgi?id=709653#c22

Based on the user feedback to us, many users do not turn on user_friendly_names but configure aliases in multipath.conf for the dm-multipath devices (using "multipaths" section) and change the names to something more meaningful like "rootlun", "installation", etc. They consider both '3600a0b800067fabc000067694d23fe6e' or 'mpatha' are not meaningful. And parameter configurations are left to their hw table defaults.

Comment 5 Martin George 2011-10-11 08:46:59 UTC
(In reply to comment #2)
> The user_friendly_names=yes usage in anaconda is deliberate.  Feedback from
> different users indicated the desire to see 'mpatha' rather than
> '3600a0b800067fabc000067694d23fe6e' in the user interface.  Most users
> requested a multitude of different ways to be able to determine what devices
> they should be using, as the user_friendly_names were really just easier on the
> eyes, but not indicative of what device was what.  

The fact is 'user_friendly_names' is error prone and has a history of being buggy - refer to bug 217014, bug 357331, bug 445268, bug 612173, bug 630911, bug 644111, bug 509095, etc. to name just a few. And as Raj rightly pointed out in comment #4, user_friendly_names is turned off by default by dm-multipath - probably because of the quality concerns involving this feature. So it doesn't seem wise to rely on a buggy feature just because it provides an aesthetic value in being pleasing to the eye. 

For the end user, it would be far safer if Anaconda sticks to the defaults instead of imposing its own preferences on a feature that is actually dm-multipath specific and nothing to do with Anaconda in the first place.

Comment 6 Chris Lumens 2011-10-11 13:14:55 UTC
As David pointed out, we have enabled this on purpose at customer request.  In general we do prefer to stick to defaults where possible, but this is one that we've gotten a lot of requests for and was an approved RHEL6 bug fix.