Bug 844335 - [engine] add correlation id for storage commands in vdsm API
[engine] add correlation id for storage commands in vdsm API
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
unspecified
x86_64 Linux
unspecified Severity medium
: ---
: 3.2.0
Assigned To: Yaniv Bronhaim
Leonid Natapov
infra
:
: 919413 950199 958258 (view as bug list)
Depends On:
Blocks: 902971 894399 948448
  Show dependency treegraph
 
Reported: 2012-07-30 06:38 EDT by Haim
Modified: 2016-02-10 14:45 EST (History)
16 users (show)

See Also:
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: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 12971 None None None Never
oVirt gerrit 13011 None None None Never

  None (edit)
Description Haim 2012-07-30 06:38:49 EDT
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 Product and Program Management 2012-12-14 03:51:21 EST
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 11:58:31 EST
Does the engine send the flow id in all commands?
Comment 6 Yaniv Bronhaim 2013-03-05 14:46:55 EST
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 13:44:29 EST
I asked from engine prospective . In vdsm nothing changed.
Comment 8 Yaniv Bronhaim 2013-03-12 08:48:49 EDT
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 03:34:01 EDT
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 04:20:07 EDT
(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 10:27:02 EDT
(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 03:02:32 EDT
*** Bug 950199 has been marked as a duplicate of this bug. ***
Comment 17 Lee Yarwood 2013-05-09 08:47:02 EDT
*** Bug 919413 has been marked as a duplicate of this bug. ***
Comment 18 Leonid Natapov 2013-05-23 12:06:19 EDT
sf17.1 fixed.
Comment 19 Lee Yarwood 2013-06-03 09:32:26 EDT
*** Bug 958258 has been marked as a duplicate of this bug. ***
Comment 20 Itamar Heim 2013-06-11 04:45:08 EDT
3.2 has been released
Comment 21 Itamar Heim 2013-06-11 04:45:12 EDT
3.2 has been released
Comment 22 Itamar Heim 2013-06-11 04:45:12 EDT
3.2 has been released
Comment 23 Itamar Heim 2013-06-11 04:51:21 EDT
3.2 has been released
Comment 24 Itamar Heim 2013-06-11 05:22:14 EDT
3.2 has been released

Note You need to log in before you can comment on or make changes to this bug.