Description of problem: I was looking at the code to see how JSON RPC broker passes the correlation-id to vdsm - it doesn't. This should be fixed. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
FYI using FlowID and correlation-id interchangeably. Correlation was a mistake. I always said it's going to come a time where we will not support it anymore and that time has come. Lets first start with why Correlation ID is completely useless. The basic idea of passing one process's context to anothers' log is never a good idea. It might seem nice at first. Being able to track calls that relate to a specific flow. But VDSM doesn't care about engine flows. VDSM, for a lot of verbs (and many more to come) would actually try and batch jobs, Run tasks in parallel, get responses from cache and more. This means that most of the information is lost when looking at the correlation ID. The correct way to filter is by Task ID, Domain ID, VM ID, etc... Those are context that VDSM understands and make's sure to log them whenever they are processes. When this was originally suggested I was opposed to it and requested for a real use case for use of this information. I was told that "it's good" but never received a concrete example. Further more, in json-rpc *every* request has an ID and that ID can be whatever you want it to be. You could make IDs be "<FlowID>_<GUID>" you could even make it "<Flow_Name>_<Flow_ID>_<GUID>" so you have something even more descriptive. In any case, I would still recommend ignoring FlowID when examining issues. I have yet to see anyone use FlowID effectively, I have only seen people mistakenly use it and filter out important information. As a side note, when event's are going to become more and more prevalent the stuff that are covered under the Task\Flow context are going to shrink. This is a good thing as Tasks are not entities in the system. To sum up, unless I get a concrete use case with a problem that can't be easily solved without Correlation ID it's going to remain unsupported. If you don't want to argue you can put it as part of the RequestID but I strongly recommend you don't.
In general, I think the thing I have to stress is that unlike the XML-RPC interface in json RPC every request has it's own request ID. This request ID is selected by the engine. This ID is recorder in both sides. Currently it's just a GUID. That means that by grepping the flowID in the engine log you should be able to see all of the request IDs and grep for them in VDSM. Also, since the engine chooses that ID it could be whatever is preferred. One possible choice is having it be "<flowID>.<incremental integer>" so every call from a flow has an ID that is directly related to the flow in the engine. That is completely unrelated to the storage TaskIDs which are currently selected by VDSM. To sum up, if just having a GUID for every request logged in the engine log and VDSM log is enough that is already available. If you require the flowID to be mangled as part of the request ID it is possible and would require some coding.
Ok Saggi, thanks for making it clear. Yes, currently none of us uses correlation ID in vdsm as it has almost not practical use. Flow ID which would be able to provide direct link in vdsm events makes indeed more sense.
we should aim to have a flowid in the vdsm log, what is the ID to be used is the stuff there is no agreement on. Let's redefine the problem we are trying to solve and continue from there.
(In reply to Barak from comment #18) > we should aim to have a flowid in the vdsm log, > what is the ID to be used is the stuff there is no agreement on. > Let's redefine the problem we are trying to solve and continue from there. Moving to 4.0 for consideration.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
As discussed in the past, this is not used, and we won't add this one at all. Closing as WONTFIX.
As far as I can tell and as bug 1339045 indicates, comment #18 never happened. There is a clear need of having a correlation between engine and vdsm sides
*** Bug 1339045 has been marked as a duplicate of this bug. ***
Hey, reopening this, since this question come up more and more in all the teams. There is definitely a need for this feature to exist. And no, with all the changes and improvements in 4.1 logging system, there is no implementation for correlation id to uniquely identify a flow top down from engine to vdsm. Or even between the parent and children commands in the engine itself.
INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Tag 'v4.19.16' doesn't contain patch 'https://gerrit.ovirt.org/77203'] gitweb: https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/tags/v4.19.16 For more info please contact: infra
This is upstream RFE and it contains fixed for VDSM, vdsm-jsonrpc-java and engine. All patches needed patches are merged, moving to ON_QA manually.
Verified downstream in bug 1458571 comment 7: > Verified in > rhevm-4.1.3.2-0.1.el7.noarch > vdsm-4.19.18-1.el7ev.x86_64 > > The flow_id in a main VDSM task is now set to the correlation ID returned by > engine. > [snip]