Open Stack

On Jan 3, 2017 19:29, "Matt Riedemann" <mriedem at linux.vnet.ibm.com> wrote:

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-python
> 35-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 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.

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).


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/34f4b1bd68d6011da76e6
8c4ddae9f28e37eed9a/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.


I am not opposed to seeing an enhancement to KSA to make your job easier
when handling exceptions.


-- 

Thanks,

Matt Riedemann



__________________________________________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170103/1149fdb7/attachment-0001.html>