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 <xi...@cn.fujitsu.com
<mailto:xi...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
