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.
As you plan on going on anyway here is my suggestion on how to push this in.
XMLRPC doesn't support named parameter, this means that you can't just ad-hoc a
new arg to all the API calls called flow-id.
For simplicity's sake lets assume they always pass the last arg as flowID if it
is a string that starts with "__FLOWID__".
What you do then is in dispatcher take the last arg and put it on the task
Have the logger print this value even when the task is in prepare next to the
You will have to make the clientIF calls use *another* dispatcher but the same
task thread pool to have this supported at the clientIF verbs as well but I
think it should have been done anyways.
----- Original Message -----
> From: "Douglas Landgraf" <dougsl...@redhat.com>
> To: "VDSM Project Development" <email@example.com>
> Sent: Thursday, February 2, 2012 12:00:44 AM
> Subject: [vdsm] flowID schema
> flowID is schema that we will be including in vdsm API to oVirt
> Engine people share the ID of engine transaction to vdsm.
> With this in hands, we will add the ID of transactions to our log.
> I would like to know your opinion how we could do that without break
> API, like include new parameters to our calls.
> Should we add at BindingXMLRPC.py -> wrapper() a code to search for a
> 'flowID' key into functions which use dict as parameter (like
>  Maybe change at other level inside BindingXMLRPC ?
> vdsm-devel mailing list
vdsm-devel mailing list