On Mon, May 15, 2017 at 6:20 AM, Sean Dague <[email protected]> wrote: > On 05/15/2017 05:59 AM, Andrey Volkov wrote: > > > >> The last time this came up, some people were concerned that trusting > >> request-id on the wire was concerning to them because it's coming from > >> random users. > > > > TBH I don't see the reason why a validated request-id value can't be > > logged on a callee service side, probably because I missed some previous > > context. Could you please give an example of such concerns? > > > > With service user I see two blocks: > > - A callee service needs to know if it's "special" user or not. > > - Until all services don't use a service user we'll not get the complete > trace. > > That is doable, but then you need to build special tools to generate > even basic flows. It means that the Elastic Search use case (where > plopping in a request id shows you things across services) does not > work. Because the child flows don't have the new id. > > It's also fine to *also* cross log the child/callee request idea on the > parent/caller, but it's not actually going to be sufficiently useful to > most people. >
+1 To me it makes sense to supply the override so that a single request-id can track multiple operations across services. But I'm struggling to find a case where passing a list(global_request_id, local_request_id) is useful. This might be something we can elaborate on later, if we find a use case for including multiple request-ids. > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
