----- Original Message -----
From: "Saggi Mizrahi" smizrahi@redhat.com To: "Keith Robertson" kroberts@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Thursday, February 9, 2012 2:24:44 PM Subject: Re: [vdsm] flowID schema
-1
I agree that for messaging environment having a Message ID is a must because you sometimes don't have a particular target so when you get a response you need to know what this node is actually responding to.
The message ID could be composed with <FLOWID><MSGID> so you can reuse the field.
But that is all besides the point.
I understand that someone might find it fun to go on following the entire flow in the Engine and in VDSM. But I would like to hear an actual use case where someone would have actually benefited from this. As I see it having VSDM return the task ID with every response (and not just for async tasks) is a lot more useful and correct.
I'd like to hear from some folks who've had to support rhev and do exactly this. Dan, Simon, care to chip in?
A generic debugging scenario as I see it.
- Something went wrong
- You go looking in the ENGINE log trying to figure out what
happend. 3. You see that ENGINE got SomeError. 4. Check to see if this error makes sense imagining that VDSM is always right and is a black box. 5. You did your digging and now you think that VDSM is as fault. 6. Go look for the call that failed. (If we returned the taskID it's pretty simple to find that call). 7. Look around the call to check VDSM state. 8. Profit.
There is never a point where you want to follow a whole flow call by call going back and forth, and even if you did having the VDSM taskID is a better anchor then flowID.
VDSM is built in a way that every call takes in to account the current state only. Debugging it with an engine flow mindset is just wrong and distracting. I see it doing more harm the good by reinforcing bad debugging practices.
----- Original Message -----
From: "Keith Robertson" kroberts@redhat.com To: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Thursday, February 9, 2012 1:34:43 PM Subject: Re: [vdsm] flowID schema
On 02/09/2012 12:18 PM, Andrew Cathrow wrote:
----- Original Message -----
From: "Ayal Baron"abaron@redhat.com To: "Dan Kenigsberg"danken@redhat.com Cc: "VDSM Project Development"vdsm-devel@lists.fedorahosted.org Sent: Monday, February 6, 2012 10:35:54 AM Subject: Re: [vdsm] flowID schema
----- Original Message -----
On Thu, Feb 02, 2012 at 10:32:49AM -0500, Saggi Mizrahi wrote:
flowID makes no sense after the initial API call as stuff like cacheing\threadpools\samplingtasks\resources\asyncTasks so flowing a flow like that will not give you the entire picture while debugging.
Also adding it now will make everything even more ugly. You know what, just imagine I wrote one of my long rambles about why I don't agree with doing this.
I cannot imagine you write anything like that. Really. I do not understand why you object logging flowID on API entry point.
The question is, what problem is this really trying to solve and is there a simpler and less obtrusive solution to that problem?
correlating logs between ovirt engine and potentially multiple vdsm nodes is a nightmare. It requires a lot skill to follow a transaction through from the front end all the way to the node, and even multiple nodes (eg actions on spm, then actions on other node to run a vm). Having a way to correlate the logs and follow a single event/flow is vital.
+1
Knowing what command caused a sequence of events in VDSM would be really helpful particularly in a threaded environment. Further, wouldn't such an ID be helpful in an asynchronous request/response model? I'm not sure what the plans are for AMQP or even if there are plans, but I'd think that something like this would be crucial for an async response. So, if you implemented it you might be killing 2 birds with 1 stone.
FYI: If you want to see examples of other systems that use similar concepts, take a look at the correlation ID in JMS.
Cheers, Keith
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel