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

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

> * batch-id

> * log_id / log_entry_id > * op_id / operation_id +1

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