Bug 844335

Summary:	[engine] add correlation id for storage commands in vdsm API
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Haim <hateya>
Component:	ovirt-engine	Assignee:	Yaniv Bronhaim <ybronhei>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Leonid Natapov <lnatapov>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, bazulay, dyasny, gwatson, hateya, iheim, lpeer, lyarwood, masayag, mkublin, mpavlik, Rhev-m-bugs, sgrinber, yeylon, ykaul, yzaslavs
Target Milestone:	---
Target Release:	3.2.0
Hardware:	x86_64
OS:	Linux
Whiteboard:	infra
Fixed In Version:	sf11	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	902971, 894399, 948448

Description Haim 2012-07-30 10:38:49 UTC

Description of problem:

when engine sends a storage command (non-virt), it uses correlation id, for example:


2012-07-30 16:48:55,575 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] (pool-4-thread-49) [5aa80001] START, ConnectStoragePoolVDSCommand(vdsId = 16cbcf58-d97a-11e1-bba6-001a4a16970e, storagePoolId = b8423a1f-8889-469a-b2fa-39ab78ac3a57, vds_spm_id = 2, masterDomainId = 4f38a996-dbeb-4981-885b-742b46a4714f, masterVersion = 1), log id: 425de2ac

when scrubbing vdsm.log for that transaction, I don't see this id any-ware in that log.

expected results: 

we should honor engine correlation id for the various commands and not only for virt command (create vm, migrate ..).

Comment 4 RHEL Program Management 2012-12-14 08:51:21 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 5 Barak 2013-03-05 16:58:31 UTC

Does the engine send the flow id in all commands?

Comment 6 Yaniv Bronhaim 2013-03-05 19:46:55 UTC

By looking in the code seems like engine puts it in each xmlprc request's header, but vdsm does not receive it. Was something changed in this area? Is it supposed to appear in all requests?

Comment 7 Yaniv Bronhaim 2013-03-06 18:44:29 UTC

I asked from engine prospective . In vdsm nothing changed.

Comment 8 Yaniv Bronhaim 2013-03-12 12:48:49 UTC

Engine puts correlationId for each operation that starts by UI or restApi. The correlation Id is printed in vdsm.log before starting the operation with the prefix [flowID: ----].

Comment 9 Yair Zaslavsky 2013-03-13 07:34:01 UTC

The above patch fixes the issue around XML PRC utils, but what about all the flows - do they send now correlation-id? please verify.

Comment 10 mkublin 2013-03-13 08:20:07 UTC

(In reply to comment #9)
> The above patch fixes the issue around XML PRC utils, but what about all the
> flows - do they send now correlation-id? please verify.

As far as I saw most of the flows are sending correlationId.
Every call to vdsm from action should send correlationId.
A calls to vdsm from IrsBroker (for example getStoragepoolInfo) or VdsManager (for example list) should not.

The only problem which is left, it is internal flows which are contains couple of actions, different correlationId will be generated for every action

Comment 11 mkublin 2013-03-13 14:27:02 UTC

(In reply to comment #10)

> The only problem which is left, it is internal flows which are contains
> couple of actions, different correlationId will be generated for every action

Fixed, patch provided to bug

Comment 16 Yair Zaslavsky 2013-04-24 07:02:32 UTC

*** Bug 950199 has been marked as a duplicate of this bug. ***

Comment 17 Lee Yarwood 2013-05-09 12:47:02 UTC

*** Bug 919413 has been marked as a duplicate of this bug. ***

Comment 18 Leonid Natapov 2013-05-23 16:06:19 UTC

sf17.1 fixed.

Comment 19 Lee Yarwood 2013-06-03 13:32:26 UTC

*** Bug 958258 has been marked as a duplicate of this bug. ***

Comment 20 Itamar Heim 2013-06-11 08:45:08 UTC

3.2 has been released

Comment 21 Itamar Heim 2013-06-11 08:45:12 UTC

3.2 has been released

Comment 22 Itamar Heim 2013-06-11 08:45:12 UTC

3.2 has been released

Comment 23 Itamar Heim 2013-06-11 08:51:21 UTC

3.2 has been released

Comment 24 Itamar Heim 2013-06-11 09:22:14 UTC

3.2 has been released