[Engine-devel] REST-API: Exposing correlation-ID

[Ori Liel]

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 at redhat.com>
To: "Eoghan Glynn" <eglynn at redhat.com>
Cc: "Ori Liel" <oliel at redhat.com>, engine-devel at 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.