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 <ken1ohmi...@gmail.com> wrote: > 2015-01-30 18:13 GMT+09:00 Simon Pasquier <spasqu...@mirantis.com>: > > On Fri, Jan 30, 2015 at 3:05 AM, Kenichi Oomichi < > oomi...@mxs.nes.nec.co.jp> > > wrote: > >> > >> > -----Original Message----- > >> > From: Roman Podoliaka [mailto:rpodoly...@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. > > > > > > 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 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 > > --- > : https://review.openstack.org/#/c/151954 > > __________________________________________________________________________ > 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