<div dir="ltr">Ok, I think at this point I'll propose a tweak to keystoneauth to make this easier, and then refactor my nova code around that.<div><br></div><div>Thanks for the help everyone.</div><div><br></div><div>Hugs and kisses,</div><div>Michael</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 4, 2017 at 4:52 PM, Morgan Fainberg <span dir="ltr"><<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@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="auto"><div><div class="h5"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jan 3, 2017 19:29, "Matt Riedemann" <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>> wrote:<br type="attribution"><blockquote class="m_-4005328480619753415quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-4005328480619753415elided-text">On 1/3/2017 8:48 PM, Michael Still wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-4005328480619753415elided-text">
So...<br>
<br>
Our python3 tests hate [1] my exception handling for continued<br>
vendordata implementation [2].<br>
<br>
Basically, it goes a bit like this -- I need to move from using requests<br>
to keystoneauth1 for external vendordata requests. This is because we're<br>
adding support for sending keystone headers with the request so that the<br>
external service can verify that it is nova talking. That bit isn't too<br>
hard.<br>
<br>
However, keystoneauth1 uses different exceptions to report errors.<br>
Conveniently, it has variables which list all of the connection and http<br>
exceptions which it might raise. Inconveniently, they're listed as<br>
strings, so I have to construct a list of them like this:<br>
<br>
# NOTE(mikal): keystoneauth makes me jump through hoops to get these<br>
# exceptions, which are listed as strings. Mutter.<br>
KEYSTONEAUTH_EXCEPTIONS = [TypeError, ValueError]<br>
for excname in ks_exceptions.connection.__all<wbr>__ +<br>
ks_exceptions.http.__all__:<br>
KEYSTONEAUTH_EXCEPTIONS.append<wbr>(getattr(ks_exceptions, excname))<br>
<br>
Then when it comes time to catch exceptions from keystoneauth1, we can<br>
just do this thing:<br>
<br>
except tuple(KEYSTONEAUTH_EXCEPTIONS) as e:<br>
LOG.warning(_LW('Error from dynamic vendordata service '<br>
'%(service_name)s at %(url)s: %(error)s'),<br>
{'service_name': service_name,<br>
'url': url,<br>
'error': e},<br>
instance=self.instance)<br>
return {}<br>
<br>
Which might be a bit horrible, but is nice in that if keystoneauth1 adds<br>
new connection or http exceptions, we get to catch them for free.<br>
<br>
This all works and is tested. However, it causes the py3 tests to fail<br>
with this exception:<br>
<br>
'TypeError: catching classes that do not inherit from BaseException is<br>
not allowed'<br>
<br>
Which is bemusing to me because I'm not very smart.<br>
<br>
So, could someone smarter than me please look at [1] and tell me why I<br>
get [2] and how to not get that thing? Answers involving manually<br>
listing many exceptions will result in me making a sad face and<br>
sarcastic comment in the code, so something more elegant than that would<br>
be nice.<br>
<br>
Discuss.<br>
<br>
Thanks,<br>
Michael<br>
<br>
<br>
1: <a href="http://logs.openstack.org/91/416391/1/check/gate-nova-python35-db/7835df3/console.html#_2017-01-04_01_10_35_520409" rel="noreferrer" target="_blank">http://logs.openstack.org/91/4<wbr>16391/1/check/gate-nova-python<wbr>35-db/7835df3/console.html#_20<wbr>17-01-04_01_10_35_520409</a><br>
2: <a href="https://review.openstack.org/#/c/415597/3/nova/api/metadata/vendordata_dynamic.py" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/415597/3/nova/api/metadata/<wbr>vendordata_dynamic.py</a><br>
<br>
--<br>
Rackspace Australia<br>
<br>
<br></div><div class="m_-4005328480619753415quoted-text">
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</div></blockquote>
<br>
My first question is, does the KSA team consider the 'connection' and 'http' variables as public / contractual to the KSA API in the library? If not, they could change/remove those and break nova which wouldn't be cool.<br></blockquote></div></div></div><div dir="auto"><br></div></div></div><div dir="auto">For what it is worth, Keystoneauth has been built very carefully so that everything that is public should be public (not prefixed with "_"), short of a massive security issue, we will not change/break an interface that is public (even not intentionally public); we may deprecated and warn if we don't want you to use the interface, but it will remain.</div><div dir="auto"><br></div><div dir="auto">The only time a public interface will be removed from KSA will be if we move to "keystoneauth2". In short, connection and HTTP variables are public today and will remain so (even if it was unintentional).</div><span class=""><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-4005328480619753415quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
For what it's worth, this is what we handle when making requests to the placement service using KSA:<br>
<br>
<a href="https://github.com/openstack/nova/blob/34f4b1bd68d6011da76e68c4ddae9f28e37eed9a/nova/scheduler/client/report.py#L37" rel="noreferrer" target="_blank">https://github.com/openstack/n<wbr>ova/blob/34f4b1bd68d6011da76e6<wbr>8c4ddae9f28e37eed9a/nova/sched<wbr>uler/client/report.py#L37</a><br>
<br>
If nothing else, maybe that's all you'd need?<br>
<br>
Another alternative is building whatever you need into KSA itself with the types you need, get that released before 1/19 (non-client library release freeze), and then use that in nova with a minimum required version bump in global-requirements.<br>
<br>
Or try to hack this out some other magical way.<font color="#888888"><br>
</font></blockquote></div></div></div><div dir="auto"><br></div></span><div dir="auto">I am not opposed to seeing an enhancement to KSA to make your job easier when handling exceptions. </div><span class=""><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-4005328480619753415quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font color="#888888"><br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann</font><div class="m_-4005328480619753415elided-text"><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></blockquote></div><br></div></div></span></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Rackspace Australia</div>
</div>