Page History

...

The initial idea of using contextIDs was to provide create a unique ID for every thread in management server, and use the NDC (aka stack) model for pushing new contexts on the stack. It was assumed that every touch point - API, new threads, async job - will correctly push and pop the contexts and ease tracking of an API call.

After discussion with architects, it was realized this has not fully materialized. Instead of modifying existing NDC code-base, it was suggested that we use MDC (aka hash) model and pass the same logContextID, up to the resource layer.

Using MDC has additional advantage that, being a hash, one can put additional information that would ease searching in logs.

References

• http://wiki.apache.org/logging-log4j/NDCvsMDC
• Using CallContext (CloudStack)
• MDC model from https://github.com/cattleio/cattle

...

All APIs, sync or async, to return logContextID logid when invoked

UI changes

None

DB changes

async_job table to have an additional column to store MDC hash (as of now only logid), which will be used to propagate information when job is dispatched to resource layer. Additionally, will be used to populate MDC back when the dispatched job returns, so that it may be tracked again on the management server side

Future enhancements

TBD

Comments