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 ..).
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.
Does the engine send the flow id in all commands?
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?
I asked from engine prospective . In vdsm nothing changed.
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: ----].
The above patch fixes the issue around XML PRC utils, but what about all the flows - do they send now correlation-id? please verify.
(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
(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
*** Bug 950199 has been marked as a duplicate of this bug. ***
*** Bug 919413 has been marked as a duplicate of this bug. ***
sf17.1 fixed.
*** Bug 958258 has been marked as a duplicate of this bug. ***
3.2 has been released