No decision about the name of the parameter yet, and this is blocking me.
Names that were suggested so far:
* flow-id
* batch-id
* log_id / log_entry_id
* op_id / operation_id
* correlation_id
* MetaTask-ID
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'?
Thanks,
Ori.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Eoghan Glynn" <eglynn(a)redhat.com>
Cc: "Ori Liel" <oliel(a)redhat.com>, engine-devel(a)ovirt.org
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.