Propagation of request id across components (heat, nova, cinder, etc)

Registered by Edmund Troche on 2013-09-25

Currently, if a request comes into nova-api (e.g.) that produces a request id which is used within nova processes (i.e. nova-api, nova-scheduler, etc), but will not get propagated to other components that may be logically related to the original request. For example, a nova-api request to create an instance will require to talk to glance, yet it seems that the request id that was generated in nova for the instance creation does not get used in glance for work performed towards that "user request" (create instance). Ideally, if a component receives an api request that includes a request id, then it should use that id for any downstream requests and all work related to that request. Propagating the request id is really out of band with respect to the API and therefore should be stored as an HTTP header (e.g. request-id). In the end, all activity related to a "top-level" request (e.g. Heat stack create) should be traceable across all components of OpenStack (nova, cinder, glance, neutron, etc).

One idea is to have the request id included in the HTTP header as "OpenStack-request-id" (note http://tools.ietf.org/html/rfc6648 deprecates use of HTTP headers starting with "X-") and have that id used in subsequent request related to other components, such that the receiving components can use that request id instead of generating its own.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

We need to take into account clients that try to spoof request ids. -- dhellmann

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.