Make tornado raise error configurable

[onorua]

What does this PR do?

Let us disable "default" tornado behavior upon request in case non 200 response is returned. By default it raise an error without checking for body of the error.

What issues does this PR fix or reference?

Systems like kubernetes provide description of error message while returning non 200 status code. Example of this message is:

status: 400
body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"asafdlakj in version \"v1\" cannot be handled as a ReplicationController: no kind \"asafdlakj\" is registered for version \"v1\"","reason":"BadRequest","code":400}

while with default raising error for the same POST query, I can got only:

        error:
            HTTP 400: Bad Request
        status:
            400

which makes impossible to create human friendly error messaging. This blocks me to push complete k8s module, as one moths of usage on our environment proved that it is impossible to manage production systems without proper logging of errors.

[rallytime]

Does this default need to be set to True? Seems like that will trigger a behavior change here.

[onorua]

On the contrary, since v4.1.0 it supports this parameter to overwrite default value which is True, also documentation for current stable tornado confirms it.

[rallytime]

Ah perfect. That's just what I was wondering. Thanks for confirming.

[onorua]

@rallytime 2016.3 is released, but I don't see the change :( When is it going to be available?

[rallytime]

@onorua This change is not available in the 2016.3.0 release because it was submitted against the develop branch. The "feature release" of 2016.3 was cut from develop a couple of months (beginning of February) before this change was submitted. As it stands right now, this change will be available in the next feature release, which is codenamed Carbon.

The process for submitting code and an explanation of which branch submissions should be made against can be found here, but basically this breaks down to "Bugs should be submitted against the earliest supported release branch that the bug appears on, and features should be submitted against develop". Does that help?

[onorua]

@rallytime will it help if I raise a bug, and close it with PR for 2016.3 branch?

[rallytime]

@onorua I have back-ported this to 2016.3 in #33680.

[onorua]

thanks!