Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

[Brandon Logan]

As a note, there will be a design session around the API refactor
efforts going on.  Microversioning will be a topic.

On Tue, 2016-04-12 at 14:59 +0200, Ihar Hrachyshka wrote:
> Xianshan  wrote:
> 
> > 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
> 
> If no one is going to help with microversioning, it won’t ever happen. I  
> suggest we consolidate whichever resources we have to get it done, instead  
> of working on small API iterations as proposed in the thread.
> 
> Ihar
> 
> __
> 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

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

[Ihar Hrachyshka]

Xianshan  wrote:


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


If no one is going to help with microversioning, it won’t ever happen. I  
suggest we consolidate whichever resources we have to get it done, instead  
of working on small API iterations as proposed in the thread.


Ihar

__
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

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

[Xie, Xianshan]

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

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

[Sean Dague]

On 04/11/2016 11:11 AM, michael mccune wrote:
> 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.

This really was the motivation in creating microversions in the first
place. There were (and still are) many issues in the API, but we kept
tripping over how the client might be able to discover / ask for newer
features. So we solved the discovery / ask for up front, and now there
is a standard mechanism (through a single monotonic value) of providing
for and asking for the new and better API. And works mostly the same
between the 4 services that have now implemented it.

That's a much better path than inventing a new mechanism entirely.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

[michael mccune]

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 > 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://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

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

[Ed Leafe]

On 04/08/2016 03:23 AM, Xie, Xianshan wrote:
> 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.

You should probably follow the guidelines set up by the API Working
Group: https://specs.openstack.org/openstack/api-wg/guidelines/headers.html

In particular, having a header that does just one thing goes against the
spirit of avoiding header proliferation.

-- 

-- Ed Leafe



signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

[Duncan Thomas]

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)

On 8 April 2016 at 11:23, Xie, Xianshan  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://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

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

[Xie, Xianshan]

Ping.

-Original Message-
From: Xie, Xianshan [mailto:xi...@cn.fujitsu.com] 
Sent: Friday, April 08, 2016 4:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cao, Shufeng/曹 树烽; doug...@parkside.io
Subject: [openstack-dev] [neutron] [API]Make API errors conform to the common 
error message without microversion

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://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-dev] [neutron] [API]Make API errors conform to the common error message without microversion

[Xie, Xianshan]

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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev