Open Stack

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-request at 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