Choosing between Request-ID middleware and Telemetry event pipeline for tracing failed VM deployments in OpenStack

Answer

When some OpenStack services do not have the oslo.middleware.RequestID middleware enabled, the Telemetry event pipeline provides the only mechanism that can guarantee end‑to‑end traceability of a failed VM deployment, provided that Telemetry is configured to emit versioned notifications containing the request_id trait.

Confirmed facts

• The RequestID middleware injects the X-OpenStack-Request-ID header into each HTTP request and logs that value in every service that has the middleware enabled in its paste.ini. If any service in the call chain lacks the middleware, the identifier is not propagated beyond that point.
• Telemetry (Ceilometer/Aodh) captures versioned notifications such as compute.instance.create.*. Starting with the OpenStack Liberty release (2015.02) and continuing in all later releases, the notification format includes a request_id trait that mirrors the API request identifier when the oslo.middleware.RequestID middleware is present in the emitting service.
• Enabling both mechanisms simultaneously does not create duplicate identifiers that confuse log‑analysis tools. The middleware writes the request ID into log lines; Telemetry stores the same identifier as a field inside the event payload. Analysis pipelines can correlate the two sources without conflict.

Likely explanation

If a service (e.g., nova-api, neutron-server, or cinder-api) is missing the RequestID middleware, the log‑based chain breaks at that service. Telemetry, however, records an event for each state transition (including failures) as soon as the service emits a notification, independent of middleware propagation. Therefore, as long as Telemetry is active and the request_id trait is populated, you can trace the failure from the API ingress through Nova, Neutron, and Cinder even when some services lack the middleware.

Steps needed for this case

1. Verify that Telemetry is enabled and configured to send versioned notifications (check ceilometer.conf or aodh.conf for notification_driver and event_definitions_cfg_file).
2. Confirm that the services involved in the VM create flow (Nova, Neutron, Cinder) are set to emit notifications with the request_id trait (this is the default in Liberty+ when oslo.middleware is installed).
3. Trigger a known failure (e.g., exceed quota) and query Telemetry for the corresponding compute.instance.create.error event, noting its request_id trait.
4. If you also need log‑level detail (e.g., exact HTTP headers or middleware‑specific debug), enable the RequestID middleware in the missing service’s paste.ini and restart the service.

Missing diagnostic detail

Can you confirm that your Telemetry deployment is configured to emit versioned notifications that include the request_id trait for compute.instance.create.* events? If the answer is no, enabling the RequestID middleware in the lacking services becomes the only reliable way to achieve end‑to‑end traceability.