Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 05/16/2017 01:28 PM, John Dickinson wrote: > I'm not sure the best place to respond (mailing list or gerrit), so > I'll write this up and post it to both places. > > I think the idea behind this proposal is great. It has the potential > to bring a lot of benefit to users who are tracing a

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 14 May 2017, at 4:04, Sean Dague wrote: > One of the things that came up in a logging Forum session is how much effort > operators are having to put into reconstructing flows for things like server > boot when they go wrong, as every time we jump a service barrier the > request-id is

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 05/16/2017 11:28 AM, Eric Fried wrote: >> The idea is that a regular user calling into a service should not >> be able to set the request id, but outgoing calls from that service >> to other services as part of the same request would. > > Yeah, so can anyone explain to me why this is a real

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

> The idea is that a regular user calling into a service should not > be able to set the request id, but outgoing calls from that service > to other services as part of the same request would. Yeah, so can anyone explain to me why this is a real problem? If a regular user wanted to be a d*ck and

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

Excerpts from Chris Dent's message of 2017-05-16 15:28:11 +0100: > On Sun, 14 May 2017, Sean Dague wrote: > > > So, the basic idea is, services will optionally take an inbound > > X-OpenStack-Request-ID which will be strongly validated to the format > > (req-$uuid). They will continue to always

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 05/16/2017 10:28 AM, Chris Dent wrote: > On Sun, 14 May 2017, Sean Dague wrote: > >> So, the basic idea is, services will optionally take an inbound >> X-OpenStack-Request-ID which will be strongly validated to the format >> (req-$uuid). They will continue to always generate one as well. When

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On Sun, 14 May 2017, Sean Dague wrote: So, the basic idea is, services will optionally take an inbound X-OpenStack-Request-ID which will be strongly validated to the format (req-$uuid). They will continue to always generate one as well. When the context is built (which is typically about 3

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 05/14/2017 07:04 AM, Sean Dague wrote: > One of the things that came up in a logging Forum session is how much > effort operators are having to put into reconstructing flows for things > like server boot when they go wrong, as every time we jump a service > barrier the request-id is reset to

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 05/15/2017 09:35 AM, Doug Hellmann wrote: > Excerpts from Sean Dague's message of 2017-05-14 07:04:03 -0400: >> One of the things that came up in a logging Forum session is how much >> effort operators are having to put into reconstructing flows for things >> like server boot when they go

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

Excerpts from Sean Dague's message of 2017-05-14 07:04:03 -0400: > One of the things that came up in a logging Forum session is how much > effort operators are having to put into reconstructing flows for things > like server boot when they go wrong, as every time we jump a service > barrier the

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 05/15/2017 08:16 AM, Lance Bragstad wrote: > > > On Mon, May 15, 2017 at 6:20 AM, Sean Dague > wrote: > > On 05/15/2017 05:59 AM, Andrey Volkov wrote: > > > >> The last time this came up, some people were concerned that trusting > >>

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On Mon, May 15, 2017 at 6:20 AM, Sean Dague 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. > > > >

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

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

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

> 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

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

> On 14 May 2017, at 13:04, Sean Dague wrote: > > One of the things that came up in a logging Forum session is how much effort > operators are having to put into reconstructing flows for things like server > boot when they go wrong, as every time we jump a service barrier the