On 1/3/2017 8:48 PM, Michael Still wrote:
So...
Our python3 tests hate [1] my exception handling for continued
vendordata implementation [2].
Basically, it goes a bit like this -- I need to move from using requests
to keystoneauth1 for external vendordata requests. This is because we're
adding support for sending keystone headers with the request so that the
external service can verify that it is nova talking. That bit isn't too
hard.
However, keystoneauth1 uses different exceptions to report errors.
Conveniently, it has variables which list all of the connection and http
exceptions which it might raise. Inconveniently, they're listed as
strings, so I have to construct a list of them like this:
# NOTE(mikal): keystoneauth makes me jump through hoops to get these
# exceptions, which are listed as strings. Mutter.
KEYSTONEAUTH_EXCEPTIONS = [TypeError, ValueError]
for excname in ks_exceptions.connection.__all__ +
ks_exceptions.http.__all__:
KEYSTONEAUTH_EXCEPTIONS.append(getattr(ks_exceptions, excname))
Then when it comes time to catch exceptions from keystoneauth1, we can
just do this thing:
except tuple(KEYSTONEAUTH_EXCEPTIONS) as e:
LOG.warning(_LW('Error from dynamic vendordata service '
'%(service_name)s at %(url)s: %(error)s'),
{'service_name': service_name,
'url': url,
'error': e},
instance=self.instance)
return {}
Which might be a bit horrible, but is nice in that if keystoneauth1 adds
new connection or http exceptions, we get to catch them for free.
This all works and is tested. However, it causes the py3 tests to fail
with this exception:
'TypeError: catching classes that do not inherit from BaseException is
not allowed'
Which is bemusing to me because I'm not very smart.
So, could someone smarter than me please look at [1] and tell me why I
get [2] and how to not get that thing? Answers involving manually
listing many exceptions will result in me making a sad face and
sarcastic comment in the code, so something more elegant than that would
be nice.
Discuss.
Thanks,
Michael
1:
http://logs.openstack.org/91/416391/1/check/gate-nova-python35-db/7835df3/console.html#_2017-01-04_01_10_35_520409
2:
https://review.openstack.org/#/c/415597/3/nova/api/metadata/vendordata_dynamic.py
--
Rackspace Australia
__________________________________________________________________________
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
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.
For what it's worth, this is what we handle when making requests to the
placement service using KSA:
https://github.com/openstack/nova/blob/34f4b1bd68d6011da76e68c4ddae9f28e37eed9a/nova/scheduler/client/report.py#L37
If nothing else, maybe that's all you'd need?
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.
Or try to hack this out some other magical way.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
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
