----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Saggi Mizrahi" <smizr...@redhat.com>
> > To: "Keith Robertson" <krobe...@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?

Agreed.  However, I can personally say that I've debugged dozens of issues 
cross components and having an anchor in the engine log (result from vdsm) was 
all I needed to find the relevant part in the vdsm log.

> 
> 
> 
> > 
> > A generic debugging scenario as I see it.
> > 
> > 1. Something went wrong
> > 2. 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" <krobe...@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"<aba...@redhat.com>
> > > >> To: "Dan Kenigsberg"<dan...@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
> > 
> _______________________________________________
> 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

Reply via email to