[openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion
michael mccune
msm at redhat.com
Mon Apr 11 15:11:29 UTC 2016
please forgive my lack of direct knowledge about the neutron process and
how this fits in. i'm just commenting from the perspective of someone
looking at this from the api-wg.
On 04/11/2016 09:52 AM, Duncan Thomas wrote:
> So by adding the handling of a header to change the behaviour of the
> API, you're basically implementing a subset of microversions, with a
> non-standard header (See the API WG spec on non-proliferation of
> headers). You'll find it takes much of the work that implementing
> microversions does, and explodes your API test matrix some more.
>
> Sounds like something that should go on hold until microversions is
> done, assuming that microversions are desired anyway. Standard error
> messages are not such a big win that they're worth non-standard headers
> and yet more API weirdness that needs to sit around potentially for a
> very long time (see the API WG rules on removing APIs, which is
> basically never)
>
i think this advice sounds reasonable. adding a side-channel around
microversions sounds like work that would itself need a microversion
bump when it is finally removed ;)
i also agree with the reasoning about the benefit from the standardized
error messages. it is nice to get a standard error message produced, but
i think adding microversions is probably a bigger win in the near term
because it will make these other transitions smoother.
> On 8 April 2016 at 11:23, Xie, Xianshan <xiexs at cn.fujitsu.com
> <mailto:xiexs at cn.fujitsu.com>> wrote:
>
> Hi, all,
>
> We are attempting to make the neutron API conform to the common
> error message format recommended by API-WG [1]. As this change will
> introduce a new error format into neutron which is different from
> existing format [2], we should think of some solutions to preserve
> the backward compat.
>
> The easiest way to do that is microversion, just like the cinder
> does [3] although which is still in progress. But unfortunately,
> there are many projects in which the microversion haven't been
> landed yet, e.g. neutron, glance, keystone etc. Thus during the
> interim period we have to find other approaches to keep the backward
> compat.
>
> According to the discussion, a new header would be a good idea to
> resolve this issue [4], we think.
> For instance:
> curl -X DELETE "http://xxx:9696/v2.0/networks/xxx" -H
> "Neutron-Common-Error-Format: True"
>
> But we haven't decided which header name will be used yet.
> So how do you think which is the best appropriate one?
> A: Neutron-Common-Error-Format
> B: OpenStack-Neutron-Common-Error-Format
> C: other (Could you please specify it? Thanks in advance)
>
> Any comments would be appreciated.
>
> [1] http://specs.openstack.org/openstack/api-wg/guidelines/errors.html
> [2] https://review.openstack.org/#/c/113570/
> [3] https://review.openstack.org/#/c/293306/
> [4] https://bugs.launchpad.net/neutron/+bug/1554869
>
> Best regards,
> xiexs
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> --
> Duncan Thomas
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list