CA-162918: DM-MP - incorrect number of paths during failover and recovery

[kostaslambda]

There is a bug in dm-multipath that does not make use of the value supplied
to dev_loss_tmo; it is always set to 'infinity'. Explicitly setting
no_path_retry to 'defaults' overcomes that bug and makes use of the value
supplied.

Signed-off-by: Kostas Ladopoulos konstantinos.ladopoulos@citrix.com

[coveralls]

Coverage remained the same at 31.66% when pulling f1069bc on kostaslamda:CA-162918 into 08d4951 on xapi-project:master.

[germanop]

I am not sure it is a bug, it could be by design: when you set it explicitly to 0 or to "fail" it is internally set to -1.
When it is not set, it is set internally to 0.
So, an explicit 0 is not like letting multipath set itself to 0.

That's said, if we want our dev_loss to be accepted, I agree that this is needed.
I would rephrase to commit message, though, removing "bug" and "setting to 'defaults' ".
The latter should be, "setting it explicitly to 0 in the defaults section"

[germanop]

For completeness we should put no_path_retry in the NETAPP section, too

[robertbreker]

Shouldn't the NetApp device entry just inherit the default?

[germanop]

Yes, but this is true for dev_loss, too, so, given they are coupled, it is either both or none

[coveralls]

Coverage remained the same at 31.66% when pulling f0bc9ac on kostaslamda:CA-162918 into 08d4951 on xapi-project:master.

[germanop]

Make sure the title reflects just the bug to fix not the consequences in our testing. However,
you can add a section in the description explaining that but remember the problem arose
because of other things, too, like our devscan removing the paths..

Title should be less than 72 chars

[coveralls]

Coverage remained the same at 31.66% when pulling f59a67b on kostaslamda:CA-162918 into 08d4951 on xapi-project:master.