Comment 2 for bug 1525259

Hi Stuart,

Thank you for comments.

I understand approach #1 mapping between glance and glanceclient.

Regarding your alternative solution for approach #2 to use request-id, we have already tried this and discussed this in cross-project sessions and comes to conclusion to add wrappers around response to add request_id.

adding hooks to requests has some drawbacks as follows:

1. The client code need to shepherd the hook function down to the calls to requests.
2. Need to modify each method call to pass request_id_list which will be a big change IMO.
3. Using this way request_id will be only used for logging purpose and not returned to caller and will not be handy to the user for tracing the logs.
4. Need changes in cross-projects as well for example nova making call to glance or cinder to glance.
5. This will not be consistent with other clients.

The requirement we are trying to meet is to make the request id available to the user of the client library. The user typically doesn't have access to the headers, so we are adding wrapper classes around response to add a request id to it which can be returned back to the caller. In case of glanceclient as it is using warlock model we are finding it difficult without making changes in schema, but In other clients it works with simple data types, as we have subclassed dict, list, etc. to add the extra property. This adds the request id to the return value without making a breaking change to the API of the client library.