<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 5:30 PM, Alexei Kornienko <span dir="ltr"><<a href="mailto:alexei.kornienko@gmail.com" target="_blank">alexei.kornienko@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi,<br><br></div>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)?<br>
</div>My IMHO is that having to write ugly hacks to handle several exception classes with the same name causes much more pain.<br></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">
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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><br></div>Regards,<br></div>Alexei<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-02-26 20:02 GMT+02:00 Dean Troyer <span dir="ltr"><<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Wed, Feb 26, 2014 at 11:20 AM, Andrey Kurilin <span dir="ltr"><<a href="mailto:akurilin@mirantis.com" target="_blank">akurilin@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">While working on unification of clients code we try to unify various exceptions in different client projects.<br>
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.<br>
</div></blockquote></div><div>[...] </div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
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.<br></div></blockquote><div><br></div></div><div>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).</div>
<div><br></div><div>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.</div><span><font color="#888888"><div>
<br></div><div>dt </div></font></span></div><span><font color="#888888"><div>
<br></div>-- <br><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br>
</font></span></div></div>
<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>