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

[Itamar Heim]

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