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

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'?

From the other options op_id/operation_id sounds best to me.

Thanks, Ori. ----- Original Message ----- From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Eoghan Glynn" <eglynn(a)redhat.com&gt; Cc: "Ori Liel" <oliel(a)redhat.com&gt;, 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. _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel