Solum resources that are exposed with "@pecan.expose" (not sure about those exposed by "@wsme_pecan.expose()") have an incorrect Content-Type value when the response is an HTTP error. For example, the response body might be something like "Plan is invalid ..." but the value of the Content-Type header will be "application/x-yaml" when it should be "text/plain". This causes problems for client side tooling (like tempest) that attempts to interpret the response body based on the value of the Content-Type header.
The reason for this is that our common exception handling code (enabled by "@exception.wrap_pecan_controller_exception") attempts to manually set the correct 'content_type' value (1), but this value is later overwritten by the pecan framework code (2). The correct mechanism to set a Content-Type that is different from the expected Content-Type is to override the declared controller template using the "pecan.override_template()" (3) method.
1.) https://github.com/stackforge/solum/blob/master/solum/common/exception.py#L154
2.) https://github.com/stackforge/pecan/blob/master/pecan/core.py#L601
3.) https://pecan.readthedocs.org/en/latest/pecan_core.html
I checked and controllers that are exposed by "@wsme_
This, however, brings up another issue. Right now, if you use the Solum API, most methods of most resources will return a JSON body with any HTTP error but *some* methods of *some* resources will return a plain text message body. This seems less than ideal. We are requiring well-written clients to be aware of this behavior. It would be better if *all* methods of *all* resources either returned plain text error messages or JSON error messages.