This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.
Debugging in CloudStack using logs is cumbersome. To ease the tracking a command through logs (and upto the resource layer), the concept of contextID and sequence numbers was introduced.
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, 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.
All APIs, sync or async, to return logid when invoked
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