)]}'
{"nova/api/metadata/vendordata_dynamic.py":[{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2cbc892a49e3bcaf4aa813f39d169826a1090ff8","unresolved":false,"context_lines":[{"line_number":114,"context_line":"                    \u0027url\u0027: url,"},{"line_number":115,"context_line":"                    \u0027error\u0027: e})"},{"line_number":116,"context_line":"            # If the vendordata service responds with Content-Type: text/html,"},{"line_number":117,"context_line":"            # (example: novajoin) and the response is an error, keystoneauth"},{"line_number":118,"context_line":"            # includes the error message in the \u0027details\u0027 attribute and not in"},{"line_number":119,"context_line":"            # the exception message. Include the \u0027details\u0027 in our logging."},{"line_number":120,"context_line":"            if isinstance(e, ks_exceptions.http.HttpError):"}],"source_content_type":"text/x-python","patch_set":1,"id":"5faad753_5a700edd","line":117,"updated":"2019-09-11 00:44:55.000000000","message":"Hm, according to the novajoin code, the response should be application/json when a Fault is raised:\n\nhttps://github.com/openstack/novajoin/blob/e8b18c4bd44ea86cbbedfdf9a9f0f7f7718c9c56/novajoin/base.py#L728\n\nbut, also according to ksa code, if the response doesn\u0027t have the expected format (top-level \"error\" key):\n\nhttps://github.com/openstack/keystoneauth/blob/38cd5fc6c39c38a51c11683884caf9696ce5f367/keystoneauth1/exceptions/http.py#L407\n\nit should show a message \"Unrecognized schema in response body.\" in our log here, but we don\u0027t see that in the logs. I don\u0027t understand why/how the log message isn\u0027t getting the detailed message from novajoin. :(","commit_id":"d9ce4efc94b01f6eccc20d6a155d3d62bdcfe5d4"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2d5373659b7ec1aa87b9b27c34bb20d831a3622b","unresolved":false,"context_lines":[{"line_number":118,"context_line":"            # includes the error message in the \u0027details\u0027 attribute and not in"},{"line_number":119,"context_line":"            # the exception message. Include the \u0027details\u0027 in our logging."},{"line_number":120,"context_line":"            if isinstance(e, ks_exceptions.http.HttpError):"},{"line_number":121,"context_line":"                msg +\u003d \u0027, Details: %s\u0027 % e.details"},{"line_number":122,"context_line":"            LOG.warning(msg, instance\u003dself.instance)"},{"line_number":123,"context_line":"            if CONF.api.vendordata_dynamic_failure_fatal:"},{"line_number":124,"context_line":"                six.reraise(type(e), e, sys.exc_info()[2])"}],"source_content_type":"text/x-python","patch_set":1,"id":"5faad753_53e54ba7","line":121,"range":{"start_line":121,"start_character":16,"end_line":121,"end_character":50},"updated":"2019-09-11 14:58:41.000000000","message":"You\u0027re trying to append to a tuple here. Not sure where to look in the CI logs, but I assume L120 is not triggering or you would see that bit blow up?","commit_id":"d9ce4efc94b01f6eccc20d6a155d3d62bdcfe5d4"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"7444bdf1e32d2e9fbe8053c6b65ef862bc027c5c","unresolved":false,"context_lines":[{"line_number":118,"context_line":"            # includes the error message in the \u0027details\u0027 attribute and not in"},{"line_number":119,"context_line":"            # the exception message. Include the \u0027details\u0027 in our logging."},{"line_number":120,"context_line":"            if isinstance(e, ks_exceptions.http.HttpError):"},{"line_number":121,"context_line":"                msg +\u003d \u0027, Details: %s\u0027 % e.details"},{"line_number":122,"context_line":"            LOG.warning(msg, instance\u003dself.instance)"},{"line_number":123,"context_line":"            if CONF.api.vendordata_dynamic_failure_fatal:"},{"line_number":124,"context_line":"                six.reraise(type(e), e, sys.exc_info()[2])"}],"source_content_type":"text/x-python","patch_set":1,"id":"5faad753_4e991e1d","line":121,"range":{"start_line":121,"start_character":16,"end_line":121,"end_character":50},"in_reply_to":"5faad753_53e54ba7","updated":"2019-09-11 15:39:07.000000000","message":"Oh, oops, I see now.\n\nIt\u0027s not something we can see in upstream CI (I don\u0027t know how to do it yet) but what I meant in my other comment is that we have a log sample [1] but it contains no error message from the vendordata service (novajoin) even though novajoin is raising an exception with a detailed message.\n\nI looked through the ksa code trying to figure out how it decides what to put in the from_response message and what I found so far I would expect it to say \"Unrecognized schema in response body\" but it doesn\u0027t. So I\u0027m clearly missing something about how either novajoin is returning an error over http or how ksa (as a client) creates the exception message on the other side.\n\nGoing to have to figure out how to recreate this in upstream CI to see what\u0027s going on, probably.\n\n[1] http://paste.openstack.org/show/775136","commit_id":"d9ce4efc94b01f6eccc20d6a155d3d62bdcfe5d4"}]}