Open Stack

Hi Ken,

1 imageRef isn't the only attribute, which could receive an image id. There
are kernelId, ramdiskId, and even bdm v2 as well. So we couldn't guess
which attribute has the invalid value.

2 Besides NotFound case, other mixed cases are there. Such as attaching of
a volume. A mountpoint can be busy, or the volume can be used by an other
instance - both cases generate a conflict error. Do you suggest to use
specially formatted message in all such cases (when the same http error
code has several reasons)? But to make a work with Nova API
straightforward, all messages should have this format, even in simplest
cases.

3 How to parse a localized message? A Nova API client shouldn't use en_us
locale only to communicate with Nova, because it should display messages
generated by Nova to an end user.



On Mon, Feb 2, 2015 at 8:28 AM, Ken'ichi Ohmichi <ken1ohmichi at gmail.com>
wrote:

> 2015-01-30 18:13 GMT+09:00 Simon Pasquier <spasquier at mirantis.com>:
> > On Fri, Jan 30, 2015 at 3:05 AM, Kenichi Oomichi <
> oomichi at mxs.nes.nec.co.jp>
> > wrote:
> >>
> >> > -----Original Message-----
> >> > From: Roman Podoliaka [mailto:rpodolyaka at mirantis.com]
> >> > Sent: Friday, January 30, 2015 2:12 AM
> >> > To: OpenStack Development Mailing List (not for usage questions)
> >> > Subject: Re: [openstack-dev] [api][nova] Openstack HTTP error codes
> >> >
> >> > Hi Anne,
> >> >
> >> > I think Eugeniya refers to a problem, that we can't really distinguish
> >> > between two different  badRequest (400) errors (e.g. wrong security
> >> > group name vs wrong key pair name when starting an instance), unless
> >> > we parse the error description, which might be error prone.
> >>
> >> Yeah, current Nova v2 API (not v2.1 API) returns inconsistent messages
> >> in badRequest responses, because these messages are implemented at many
> >> places. But Nova v2.1 API can return consistent messages in most cases
> >> because its input validation framework generates messages
> >> automatically[1].
> >
> >
> > When you say "most cases", you mean JSON schema validation only, right?
> > IIUC, this won't apply to the errors described by the OP such as invalid
> key
> > name, unknown security group, ...
>
> Yeah, right.
> I implied that in "most cases" and I have one patch[1] for covering them.
> By the patch, the sample messages also will be based on the same
> format and be consistent.
> The other choice we have is CamelCase exception as the fist mail, that
> also is interesting.
>
> Thanks
> Ken Ohmichi
>
> ---
> [1]: https://review.openstack.org/#/c/151954
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150202/d92cf3ac/attachment.html>