Open Stack

> -----Original Message-----
> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
> Sent: Wednesday, January 27, 2016 9:56 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][glance][cinder][neutron]How to make
> use of x-openstack-request-id
> 
> 
> 
> On 1/27/2016 9:40 AM, Tan, Lin wrote:
> > Thank you so much. Eron. This really helps me a lot!!
> >
> > Tan
> >
> > *From:*Kuvaja, Erno [mailto:kuvaja at hpe.com]
> > *Sent:* Tuesday, January 26, 2016 8:34 PM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [nova][glance][cinder][neutron]How to
> > make use of x-openstack-request-id
> >
> > Hi Tan,
> >
> > While the cross project spec was discussed Glance already had
> > implementation of request ids in place. At the time of the Glance
> > implementation we assumed that one request id is desired through the
> > chain of services and we implemented the req id to be accepted as part
> > of the request. This was mainly driven to have same request id through
> > the chain between glance-api and glance-registry but as the same code
> > was used in both api and registry services we got this functionality
> > across glance.
> >
> > The cross project discussion turned this approach down and decided
> > that only new req id will be returned. We did not want to utilize 2
> > different code bases to handle req ids in glance-api and
> > glance-registry, nor we wanted to remove the functionality to allow
> > the req ids being passed to the service as that was already merged to
> > our API. Thus is requests are passed without req id defined to the
> > services they behave (apart from nova having different header name)
> > same way, but with glance the request maker has the liberty to specify
> > request id they want to use (within configured length limits).
> >
> > Hopefully that clarifies it for you.
> >
> > -Erno
> >
> > *From:*Tan, Lin [mailto:lin.tan at intel.com]
> > *Sent:* 26 January 2016 01:26
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [nova][glance][cinder][neutron]How to
> > make use of x-openstack-request-id
> >
> > Thanks Kebane, I test glance/neutron/keystone with
> > ``x-openstack-request-id`` and find something interesting.
> >
> > I am able to pass ``x-openstack-request-id``  to glance and it will
> > use the UUID as its request-id. But it failed with neutron and keystone.
> >
> > Here is my test:
> >
> > http://paste.openstack.org/show/484644/
> >
> > It looks like because keystone and neutron are using
> > oslo_middleware:RequestId.factory and in this part:
> >
> >
> https://github.com/openstack/oslo.middleware/blob/master/oslo_middlew
> a
> > re/request_id.py#L35
> >
> > It will always generate an UUID and append to response as
> > ``x-openstack-request-id`` header.
> >
> > My question is should we accept an external passed request-id as the
> > project's own request-id or having its unique request-id?
> >
> > In other words, which one is correct way, glance or neutron/keystone?
> > There must be something wrong with one of them.
> >
> > Thanks
> >
> > B.R
> >
> > Tan
> >
> > *From:*Kekane, Abhishek [mailto:Abhishek.Kekane at nttdata.com]
> > *Sent:* Wednesday, December 2, 2015 2:24 PM
> > *To:* OpenStack Development Mailing List
> > (openstack-dev at lists.openstack.org
> > <mailto:openstack-dev at lists.openstack.org>)
> > *Subject:* Re: [openstack-dev] [nova][glance][cinder][neutron]How to
> > make use of x-openstack-request-id
> >
> > Hi Tan,
> >
> > Most of the OpenStack RESTful API returns `X-Openstack-Request-Id` in
> > the API response header but thisrequest id isnotavailable to the
> > callerfromthe python client.
> >
> > When you use --debug option from command from the command prompt
> using
> > client, you can see `X-Openstack-Request-Id`on the console but it is
> > not logged anywhere.
> >
> > Currently a cross-project specs [1] is submitted and approved for
> > returning X-Openstack-Request-Id to the caller and the implementation
> > for the same is in progress.
> >
> > Please go through the specs for detail information which will help you
> > to understand more about request-ids and current work about the same.
> >
> > Please feel free to revert back anytime for your doubts.
> >
> > [1]
> > https://github.com/openstack/openstack-
> specs/blob/master/specs/return-
> > request-id.rst
> >
> > Thanks,
> >
> > Abhishek Kekane
> >
> > Hi guys
> >
> >          I recently play around with 'x-openstack-request-id' header
> > but have a dump question about how it works. At beginning, I thought
> > an action across different services should use a same request-id but
> > it looks like this is not the true.
> >
> > First I read the spec:
> > https://blueprints.launchpad.net/nova/+spec/cross-service-request-id
> > which said "This ID and the request ID of the other service will be
> > logged at service boundaries". and I see cinder/neutron/glance will
> > attach its context's request-id as the value of "x-openstack-request-id"
> > header to its response while nova use X-Compute-Request-Id. This is
> > easy to understand. So It looks like each service should generate its
> > own request-id and attach to its response, that's all.
> >
> > But then I see glance read 'X-Openstack-Request-ID' to generate the
> > request-id while cinder/neutron/nova read 'openstack.request_id' when
> > using with keystone. It is try to reuse the request-id from keystone.
> >
> > This totally confused me. It would be great if you can correct me or
> > point me some reference. Thanks a lot
> >
> > Best Regards,
> >
> > Tan
> >
> >
> >
> __________________________________________________________
> ____________
> > Disclaimer: This email and any attachments are sent in strictest
> > confidence for the sole use of the addressee and may contain legally
> > privileged, confidential, and proprietary data. If you are not the
> > intended recipient, please advise the sender by replying promptly to
> > this email and then delete and destroy this email and any attachments
> > without any further use, copying or forwarding.
> >
> >
> >
> >
> __________________________________________________________
> ____________
> > ____ OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> I haven't read into the cross-project spec, but I can say that from a debugging
> perspective, it would be nice if the same request ID was used throughout a
> call chain, i.e. tempest is making a request to the nova API which is making
> requests to cinder, glance, keystone and neutron.
> Something fails in let's say neutron, it'd be nice to be following that request
> ID throughout the service logs for the same operation that originated in
> Tempest. Instead of being able to use the request ID, you often times have
> to use the instance uuid to track the device_id in the neutron logs, or a
> volume_id in the n-cpu logs back to the c-api/c-vol logs.
> 
> Or am I missing something?

Nope, that's one of the reasons we wanted to have that same id possibly initiated by client to follow through the whole life of the request. This wasn't good enough for some folks for various reasons; security card was obviously played, another big part of discussion was request separation when we need to send request to same service multiple times during action (for example in Glance creating an image and uploading the data to it are two different API calls to glance even it's one action from user). Debugging/support/monitoring wise it would be great if one could specify desired request ID for action and follow it through, but unfortunately that wasn't the agreed approach in the community.

- Erno

> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev