Bug 1272026

Summary:	Use obtain_device_list_from_udev=1 vdsm private lvm configuration
Product:	[oVirt] vdsm	Reporter:	Nir Soffer <nsoffer>
Component:	Core	Assignee:	Fred Rolland <frolland>
Status:	CLOSED DUPLICATE	QA Contact:	Aharon Canan <acanan>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	4.17.9	CC:	bugs, nsoffer, ylavi
Target Milestone:	ovirt-4.0.0-alpha	Flags:	ylavi: ovirt-4.0.0? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	storage
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-22 19:13:42 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nir Soffer 2015-10-15 10:03:52 UTC

Description of problem:

Vdsm overrides lvm configuration for vdsm lvm calls. We are using 
obtain_device_list_from_udev=0 which was a workaround for old udev
bugs in EL 6.

The udev issues should be fixed in Fedora 21 and EL 7.

Test vdsm without obtain_device_list_from_udev=0 and remove this
option if it works now.

The advantage should be faster operation as lvm does not have to search
/dev for block devices but get the devices from udev.

See https://bugzilla.redhat.com/show_bug.cgi?id=1259587#c11

Comment 1 Yaniv Kaul 2015-10-20 09:54:53 UTC

What's the priority of this bug? Do we want it for 3.6.0?

Comment 2 Nir Soffer 2015-10-22 19:05:20 UTC

(In reply to Yaniv Kaul from comment #1)
> What's the priority of this bug? Do we want it for 3.6.0?

This is cleanup, using the platform as it was meant to be used, avoiding
problematic .cache files (that were broken recently in 7.2).

We want it in 3.6, but it is not urgent. Since the trivial patch is
ready and tested, I don't see a reason to wait.

ydary: this should be in next 3.6 release.

Comment 3 Nir Soffer 2015-10-22 19:13:42 UTC

Strange, we have this bug twice - this is a duplicate of bug 1272027.

I cannot explain how we have the same bug twice - maybe bugzilla failed
but created the bug, and I submitted again?

*** This bug has been marked as a duplicate of bug 1272027 ***