Comment 7 for bug 1554869

Hi, Armando & Doug & Ihar,
Thanks a lot for your review.

>are these api error changes additive, or will we be breaking backwards compatibility to switch?
Actually I have ever considered the former pattern which described by the patch set 1 (#298704). In this pattern, the old message and the new message will be output together.

But according to your tips, I think the later one will be a better idea.
Then the following solution will be proposed to preserve the backwards compatibility:

We will suppose a new field, named as 'Neutron-Common-Error-Format' temporarily , in the HTTP header that is sent to the neutron APIs.
And then based on whether the field is specified or not, or which value is set to the option, we can maintain the backwards compatibility, i.e.:
 - Keep the old error format if that field is not specified or set to False.
   Which means there is not any changes to the existing error message, and in this case the users and the existing APPs won't feel any changes at all.
   By default, neutron APIs will work with this pattern.

 - Return the new error format while that field is specified and meanwhile is set to True.
   In this case, the option must be explicitly set to True and it will break the backwards compatibility.

Does it make sense to you?
Or I will really appreciate if you guys tell me a better idea, thanks in advance.