On Wed, Feb 26, 2014 at 5:30 PM, Alexei Kornienko < alexei.kornie...@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 <dtro...@gmail.com>: > >> On Wed, Feb 26, 2014 at 11:20 AM, Andrey Kurilin >> <akuri...@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 >> dtro...@gmail.com >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
