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

[Moti Asayag]

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

flow-id is the name used by VDSM logs for logging this value (e.g.
flowID w23rew34)
+1

> * batch-id
> * log_id / log_entry_id
> * op_id / operation_id
> * correlation_id

correlation-ID is the name used by the ovirt engine, however, it is a
bit too long, yet +1.

> * 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.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel