Bug 1430822

Summary:	pvscan/vgscan/lvscan/lvmdiskscan need to call function "lvmnotify_send" too
Product:	[Community] LVM and device-mapper	Reporter:	Tony Asleson <tasleson>
Component:	lvm2	Assignee:	LVM Team <lvm-team>
lvm2 sub component:	Command-line tools	QA Contact:	cluster-qe <cluster-qe>
Status:	NEW ---	Docs Contact:
Severity:	unspecified
Priority:	high	CC:	agk, heinzm, jbrassow, msnitzer, prajnoha, teigland, thornber, zkabelac
Version:	2.02.167	Keywords:	Triaged
Target Milestone:	---	Flags:	rule-engine: lvm-technical-solution? rule-engine: lvm-test-coverage?
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tony Asleson 2017-03-09 16:14:31 UTC

Description of problem:

If a user runs any of the scan command line tools the lvm dbus service does not get an event which tells it to update it's state.

Additionally if a user does a `wipefs -a /dev/sdc` on a PV or a disk that contains a PV(s) simply disappears, the lvm dbus service needs to be aware of this event too.  Perhaps a udev rule that runs pvscan which in turn would generate an event to the lvm dbus service?  

Note: The dbus service disables udev monitoring when lvm delivers an event to the lvm dbus service via the function lvmnotify_send.


Version-Release number of selected component (if applicable):

LVM version:     2.02.167(2) (2016-11-05)
Library version: 1.02.136 (2016-11-05)
Driver version:  4.35.0


How reproducible:
100%


Steps to Reproduce:
1.Run the lvm dbus service with --debug
2.Create something from the command line, eg. vgcreate
3.Note that the service gets a udev event and a lvm event and disables udev
4.wipefs -a <some pv>, note that the lvm dbus service is unaware
5.run pvscan --cache from command line and see that the lvm service is still unaware

Actual results:
lvm dbus service does not know of state change


Expected results:
lvm dbus service is notified of state change


Additional info:

Comment 1 David Teigland 2017-03-09 16:39:26 UTC

First to clarify how this is part of a broader issue...  Both lvmetad and lvmdbusd cache information about device state and lvm state.  If device/lvm state is modified through lvm tools, then lvm can update the state in lvmetad/lvmdbusd.  But, if device/lvm state is modified by non-lvm tools, then lvmetad/lvmdbusd are not updated.

To work around this problem, the command 'pvscan --cache' exists so a person can manually refresh all the lvmetad state.  lvmdbusd needs the same kind of thing, so a user can manually refresh all the lvmdbusd state.  Is the command 'vgscan --notifydbus' sufficent for this, or do we need something more?

Comment 2 Tony Asleson 2017-03-09 16:54:19 UTC

(In reply to David Teigland from comment #1)
> First to clarify how this is part of a broader issue...  Both lvmetad and
> lvmdbusd cache information about device state and lvm state.  If device/lvm
> state is modified through lvm tools, then lvm can update the state in
> lvmetad/lvmdbusd.  But, if device/lvm state is modified by non-lvm tools,
> then lvmetad/lvmdbusd are not updated.
> 
> To work around this problem, the command 'pvscan --cache' exists so a person
> can manually refresh all the lvmetad state.  lvmdbusd needs the same kind of
> thing, so a user can manually refresh all the lvmdbusd state.  Is the
> command 'vgscan --notifydbus' sufficent for this, or do we need something
> more?

I would like to see all the "scan" tools simply kick the lvm dbus service to ensure it's up to date.  My preference would be for the user to not have to explicitly pass something on the lvm command line to do this as it's really an implementation detail IMHO.

Comment 3 David Teigland 2017-03-09 17:21:57 UTC

Sounds reasonable to make the 'scan --cache' commands automatically generate a dbus signal.  Trivial patch; I'll do this after 7.4 changes are done.