On 05/14/2012 03:18 PM, Yair Zaslavsky wrote:
On 05/14/2012 02:19 PM, Ori Liel wrote:
No decision about the name of the parameter yet, and this is blocking me.
Names that were suggested so far:
* flow-id
+1
* batch-id
+1
* log_id / log_entry_id
* op_id / operation_id
+1
-1 from me, as this is about a group of operations .
* correlation_id
+1
* MetaTask-ID
-1, too pompous?
a maybe to remove the "ID" from name, since there is no uniqueness
guarantee.
It seems like the only purpose of this feature is logging, so I'm
voting for 'log_entry_id' (although I consider some of the other options
viable as well). Does someone disagree with 'log_entry_id'?
IMHO, log_entry_id shounds "too generic" to me. Maybe in the future we
would like to expose other logging/tracking to REST-API?
From the other options op_id/operation_id sounds best to me.
Thanks,
Ori.
----- Original Message -----
From: "Itamar Heim"<[email protected]>
To: "Eoghan Glynn"<[email protected]>
Cc: "Ori Liel"<[email protected]>, [email protected]
Sent: Tuesday, May 8, 2012 12:40:25 PM
Subject: Re: [Engine-devel] REST-API: Exposing correlation-ID
On 05/08/2012 12:00 PM, Eoghan Glynn wrote:
1) what's the name you'd give this parameter? job-id? batch-id?
flow-id? command-id? correlation-id???
job-id will confuse us with engine's job-id which is a single
command
today.
correleation-id is pretty long and confusing as implies on
correlation
of something.
I'm for flow-id or batch-id.
batch-id sounds the right one to me, as this is identifying a
batch
of
calls.
How about log-id?
It isn't supposed to be unique, or of any format, it's just used to
log calls, so log-id is the most natural (or log-tag or whatever
name you prefer).
Also I think it's more of a header-type parameter since it's
metadata for the call, not an actual parameter that influences the
outcome of the "flow".
I actually believe you're right, it probably is better to pass this parameter as
an http header. You've changed my mind about this (objections, anyone, to
passing
it as a header as opposed to passing it as a url parameter)?
Agree also that a header is much more natural in this case than a URL parameter.
Also in the case where the client does not specify the ID themselves on the
initial request, a generated value should be returned as response header
(so that this can be passed as request header with the next request if part
of the same over-arching task, or else just to aid log interpretation if the
initial request was standalone but still mapped internally to multiple backend
actions).
About log_id - it could sound like there are numerous logs, and the user is
asked
to specify the ID of the log he wishes to write to. But perhaps: log_entry_id?
Is there any possibility that this identifier may be leveraged for uses other
than
log interpretation?
One other suggestion to add into the mix: MetaTask-ID.
the one thing mentioned in the thread and worth remembering is this ID
is not unique, as client can set it as they want.
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
