On 05/03/2012 09:49 PM, Ori Liel wrote:
...
Hi Ori,
Is the intent here to allow correlation between multiple backend actions
initiated from a single restapi call, or an over-arching correlation
across multiple restapi calls?
If the former, then I'd agree with Yaniv, just generate the ID internally
and return it as a response header.
If the latter, then allowing it to be optionally set via a request header,
seems more natural to me than a URL parameter because this is additional
out-of-band data that aids in log interpretation, as opposed to something
directly germane to the interaction with the target resource.
both.
engine auto-generates this if not provided and domain is single command.
but client can pass this to see all events or multiple commands running
in parallel as part of same single client logical action.
Right, when user passes a correlation ID on the http request, all calls to
the Backend, that are done in the context of this request, will have this
correlation-ID (and thus appear in the log as part of the same operation).
But when I think about it, why should the user be involved? If a REST
action - for example restore-snapshot - involves more than one call to the
Backend, REST-API (not the user) can decide to always attach a hard-coded,
descriptive correlation ID to these calls.
true, if API performs multiple actions it should self-generated the ID
on its own (just like the backend does).
In trying to justify letting the user set the correlation ID, I came up with
the following scenarios:
* the user wants to analyze an action in the log, but the server is shared by
many users. It would be easier to look for "ori's_restore_snapshot" than for
the generic "restore_snapshot", because maybe other users restored snapshots.
* tester wants to run the same action 50 times with different parameters, and
see the actions in the log as: "restore_snapshot_test_1",
"restore_snapshot_test_2",
etc.
So in summary, I think there is some value in letting the user set the value.
another use case - user wants to write their own feature of managing VM
pools.
user creates a group of VMs via a single action in the UI created on top
of the REST API.
as far as user is concerned, the 30 VMs created by their action, events,
and statuses are all part of the same meta-action, so all should have
the same batch id.
Ori
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
