Open Stack

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.fainberg at gmail.com>
wrote:

>
>
> 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: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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Rackspace Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170105/96fceac3/attachment.html>