Thanks for the replies!

> Could you elaborate bit what you want to have in the headers and why? Our
plan has been so > far having the error code in the message payload so that
it?s easily available for users and

> operators.  What this library you?re proposing would be actually doing?

I’ve already read specs, proposed in glance about error codes.Actually I
don’t prefer leave such content in message payload at least due to the fact
error messages is translated, and can be changed while transmitting. Also,
as far as I remember in some openstack projects (can’t say more precisely
where) error messages is generated in the strange way, and put something
new in it will be hard, also some problems will appear while extracting.

> We?re more than happy to take extra hands on this so please follow up the
[log] discussion

> and feel free to contact me (IRC: jokke_) or Rockyg (in cc as well)
 around what has been

> done and planned in case you need more clarification.

Thanks, I’ll contact you via IRC.

> I'm not sure a single library as a home to all of the various error

> messages is the right approach. I thought, based on re-reading the

> thread you link to, that the idea was to come up with a standard schema

> for error payloads and then let the projects fill in the details. We

> might need a library for utility functions, but that wouldn't actually

> include the error messages.

Sure, maybe I wrongly spoke it. Library definitely shouldn’t contain  error
messages, errors or something like this - if so it will make managing
errors much more difficult. it should have stuff to put/extract header from
response and, you are right, other needed utilities.

On Wed, Feb 25, 2015 at 4:33 PM, Eugeniya Kudryashova <
ekudryash...@mirantis.com> wrote:

> Hi, stackers!
>
> As was suggested in topic [1], using an HTTP header was a good solution
> for communicating common/standardized OpenStack API error codes.
>
> So I’d like to begin working on a common library, which will collect all
> openstack HTTP API errors, and assign them string error codes. My suggested
> name for library is openstack.error, but please feel free to propose
> something different.
>
> The other question is where we should allocate such project, in openstack
> or stackforge, or maybe oslo-incubator? I think such project will be too
> massive (due to dealing with lots and lots of exceptions)  to allocate it
> as a part of oslo, so I propose developing the project on Stackforge and
> then eventually have it moved into the openstack/ code namespace when the
> other projects begin using the library.
>
> Let me know your feedback, please!
>
>
> [1] -
> http://lists.openstack.org/pipermail/openstack-dev/2015-January/055549.html
>
__________________________________________________________________________
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

Reply via email to