[openstack-dev] [python-*client] moving to WebOb exceptions

Doug Hellmann doug.hellmann at dreamhost.com
Wed Feb 26 23:16:44 UTC 2014


On Wed, Feb 26, 2014 at 5:30 PM, Alexei Kornienko <
alexei.kornienko at gmail.com> wrote:

> Hi,
>
> Could you please explain in more details what causes pain in adding
> additional requirement to clients (in most cases when client is used inside
> other openstack projects it's there already)?
> My IMHO is that having to write ugly hacks to handle several exception
> classes with the same name causes much more pain.
>

We want to reduce the dependencies our clients introduce on projects that
use them because we don't want to introduce conflicts. The exceptions will
be unified when the client code moves out into its own library, which
achieves the same thing as using WebOb exceptions, with the additional
benefit that the exceptions are in our namespace and we can therefore give
them more meaningful names depending on the context where they are being
used.

I'm unclear how the work you're doing relates to the Python SDK project,
though. Are we still going to spend time and effort cleaning up the
existing clients if we're going to deprecate them in favor of something new?

Doug



>
> Regards,
> Alexei
>
>
> 2014-02-26 20:02 GMT+02:00 Dean Troyer <dtroyer at gmail.com>:
>
>> On Wed, Feb 26, 2014 at 11:20 AM, Andrey Kurilin <akurilin at mirantis.com>wrote:
>>
>>> While working on unification of clients code we try to unify various
>>> exceptions in different client projects.
>>> We have module apiclient.exceptions in oslo-incubator[1]. Since our
>>> apiclient is an oslo-inclubator library and not a standalone lib this
>>> doesn't help in case we need to process exceptions from several clients.
>>>
>> [...]
>>
>>> The solution would be to use exceptions from external library - Module
>>> WebOb.exc[2] for example (since WebOb is already used in other openstack
>>> projects). This exceptions cover all our custom http exceptions.
>>>
>>
>> I would oppose adding WebOb as a requirement for the client libraries.  I
>> see keystoneclient has it today but that is only because the middleware is
>> still in that repo (moving those is another topic).
>>
>> The pain of installing the exiting client libs and their prereqs is bad
>> enough, adding to it is not tenable and is part of what is motivating the
>> SDK efforts.
>>
>> dt
>>
>> --
>>
>> Dean Troyer
>> dtroyer at gmail.com
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140226/762b50c2/attachment.html>


More information about the OpenStack-dev mailing list