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.
Thanks for the help everyone. Hugs and kisses, Michael On Wed, Jan 4, 2017 at 4:52 PM, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > On Jan 3, 2017 19:29, "Matt Riedemann" <mrie...@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-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > 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 > > -- 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