Open Stack

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, ...

Thanks,
Simon


>
> Thanks
> Ken'ichi Ohmichi
>
> ---
> [1]:
> https://github.com/openstack/nova/blob/master/nova/api/validation/validators.py#L104
>
> > On Thu, Jan 29, 2015 at 6:46 PM, Anne Gentle
> > <annegentle at justwriteclick.com> wrote:
> > >
> > >
> > > On Thu, Jan 29, 2015 at 10:33 AM, Eugeniya Kudryashova
> > > <ekudryashova at mirantis.com> wrote:
> > >>
> > >> Hi, all
> > >>
> > >>
> > >> Openstack APIs interact with each other and external systems
> partially by
> > >> passing of HTTP errors. The only valuable difference between types of
> > >> exceptions is HTTP-codes, but current codes are generalized, so
> external
> > >> system can’t distinguish what actually happened.
> > >>
> > >>
> > >> As an example two different failures below differs only by error
> message:
> > >>
> > >>
> > >> request:
> > >>
> > >> POST /v2/790f5693e97a40d38c4d5bfdc45acb09/servers HTTP/1.1
> > >>
> > >> Host: 192.168.122.195:8774
> > >>
> > >> X-Auth-Project-Id: demo
> > >>
> > >> Accept-Encoding: gzip, deflate, compress
> > >>
> > >> Content-Length: 189
> > >>
> > >> Accept: application/json
> > >>
> > >> User-Agent: python-novaclient
> > >>
> > >> X-Auth-Token: 2cfeb9283d784cfba694f3122ef413bf
> > >>
> > >> Content-Type: application/json
> > >>
> > >>
> > >> {"server": {"name": "demo", "imageRef":
> > >> "171c9d7d-3912-4547-b2a5-ea157eb08622", "key_name": "test",
> "flavorRef":
> > >> "42", "max_count": 1, "min_count": 1, "security_groups": [{"name":
> "bar"}]}}
> > >>
> > >> response:
> > >>
> > >>     HTTP/1.1 400 Bad Request
> > >>
> > >> Content-Length: 118
> > >>
> > >> Content-Type: application/json; charset=UTF-8
> > >>
> > >> X-Compute-Request-Id: req-a995e1fc-7ea4-4305-a7ae-c569169936c0
> > >>
> > >> Date: Fri, 23 Jan 2015 10:43:33 GMT
> > >>
> > >>
> > >> {"badRequest": {"message": "Security group bar not found for project
> > >> 790f5693e97a40d38c4d5bfdc45acb09.", "code": 400}}
> > >>
> > >>
> > >> and
> > >>
> > >>
> > >> request:
> > >>
> > >> POST /v2/790f5693e97a40d38c4d5bfdc45acb09/servers HTTP/1.1
> > >>
> > >> Host: 192.168.122.195:8774
> > >>
> > >> X-Auth-Project-Id: demo
> > >>
> > >> Accept-Encoding: gzip, deflate, compress
> > >>
> > >> Content-Length: 192
> > >>
> > >> Accept: application/json
> > >>
> > >> User-Agent: python-novaclient
> > >>
> > >> X-Auth-Token: 24c0d30ff76c42e0ae160fa93db8cf71
> > >>
> > >> Content-Type: application/json
> > >>
> > >>
> > >> {"server": {"name": "demo", "imageRef":
> > >> "171c9d7d-3912-4547-b2a5-ea157eb08622", "key_name": "foo",
> "flavorRef":
> > >> "42", "max_count": 1, "min_count": 1, "security_groups": [{"name":
> > >> "default"}]}}
> > >>
> > >> response:
> > >>
> > >> HTTP/1.1 400 Bad Request
> > >>
> > >> Content-Length: 70
> > >>
> > >> Content-Type: application/json; charset=UTF-8
> > >>
> > >> X-Compute-Request-Id: req-87604089-7071-40a7-a34b-7bc56d0551f5
> > >>
> > >> Date: Fri, 23 Jan 2015 10:39:43 GMT
> > >>
> > >>
> > >> {"badRequest": {"message": "Invalid key_name provided.", "code": 400}}
> > >>
> > >>
> > >> The former specifies an incorrect security group name, and the latter
> an
> > >> incorrect keypair name. And the problem is, that just looking at the
> > >> response body and HTTP response code an external system can’t
> understand
> > >> what exactly went wrong. And parsing of error messages here is not
> the way
> > >> we’d like to solve this problem.
> > >
> > >
> > > For the Compute API v 2 we have the shortened Error Code in the
> > > documentation at
> > >
> http://developer.openstack.org/api-ref-compute-v2.html#compute_server-addresses
> > >
> > > such as:
> > >
> > > Error response codes
> > > computeFault (400, 500, …), serviceUnavailable (503), badRequest (400),
> > > unauthorized (401), forbidden (403), badMethod (405), overLimit (413),
> > > itemNotFound (404), buildInProgress (409)
> > >
> > > Thanks to a recent update (well, last fall) to our build tool for docs.
> > >
> > > What we don't have is a table in the docs saying "computeFault has this
> > > longer Description" -- is that what you are asking for, for all
> OpenStack
> > > APIs?
> > >
> > > Tell me more.
> > >
> > > Anne
> > >
> > >
> > >>
> > >>
> > >> Another example for solving this problem is AWS EC2 exception codes
> [1]
> > >>
> > >>
> > >> So if we have some service based on Openstack projects it would be
> useful
> > >> to have some concrete error codes(textual or numeric), which could
> allow to
> > >> define what actually goes wrong and later correctly process obtained
> > >> exception. These codes should be predefined for each exception, have
> > >> documented structure and allow to parse exception correctly in each
> step of
> > >> exception handling.
> > >>
> > >>
> > >> So I’d like to discuss implementing such codes and its usage in
> openstack
> > >> projects.
> > >>
> > >>
> > >> [1] -
> > >>
> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html
> > >>
> > >>
> __________________________________________________________________________
> > >> 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
> > >>
> > >
> > >
> > >
> > > --
> > > Anne Gentle
> > > annegentle at justwriteclick.com
> > >
> > >
> __________________________________________________________________________
> > > 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
> > >
> >
> >
> __________________________________________________________________________
> > 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
> __________________________________________________________________________
> 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/20150130/9958735e/attachment.html>