----- Original Message -----
> On 02/12/2012 02:50 AM, Dan Kenigsberg wrote:
> > On Thu, Feb 09, 2012 at 03:23:19PM -0500, Ayal Baron wrote:
> >>
> >> ----- Original Message -----
> >>> -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.
> >>>
> >>> 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.
> >> I don't know about harm, but, today the engine logs every call and
> >> return value to and from vdsm.  This means that all the info that
> >> is needed to follow a flow is already present in the engine log
> >> (which was not the case previously) so I believe that the flow id
> >> is redundant.
> >> In addition, instead of focusing on how to track a flow between
> >> components, we should focus on how to improve the engine log so
> >> that the users don't need to go to the hosts in the first place.
> >> My biggest problem with it is that it changes each and every verb
> >> in the API and makes the log itself also more verbose and less
> >> readable.
> > The good thing about the currently suggested implementation
> >
> > http://gerrit.ovirt.org/#patch,sidebyside,1221,6,vdsm/BindingXMLRPC.py
> >
> > is that it (ab)uses an http header for carrying FlowID,
> Yes, it certainly does appear to overload it.  I would be nice to
> have
> something formal given to it by engine, but I can appreciate the
> difficulty implementing such a scheme.

Technically I disagree, this is a cross cutting concern which has nothing to do 
with any specific call hence it should be passed as a header, that is actually 
rather elegant.

To the specific matter at hand though. what would really be nice is solving the 
real problem properly, and not contaminating the API and the log with things 
which have marginal benefit if at all.

> 
> >   thus keeping the
> > formal API intact. FlowID is logged only on API entry point, so it
> > would
> > not clutter the logs too much.
> > Keith, Dan, I will need your support in Gerrit for the patch.
> +1 if I am asked to review.
> > Dan.
> 
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to