Hi, Duncan & michael, Thanks a lot for your replies. Definitely I agree with you that the microversion is the best approach to solve the backwards compat, and the neutron is also going to adopt it [1]. But it will take a long time to totally introduce it into neutron I think. So IMO, we can continue this discussion and then implement this feature in parallel with the microversion.
Actually, according to the design [2], only a slight change will be done once the microversion landed, i.e. replace the ' new header ' with the microversion to control the final format about the error message in the wsgi interface. [1] https://review.openstack.org/#/c/136760/ [2] https://review.openstack.org/#/c/298704 Best regards, xiexs -----Original Message----- From: michael mccune [mailto:m...@redhat.com] Sent: Monday, April 11, 2016 11:11 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion 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 __________________________________________________________________________ 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
