[dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors

Morgan Fainberg morgan.fainberg at gmail.com
Fri Dec 14 15:45:20 UTC 2018


The issue was with OpenStack SDK. SDK is doing a strange thing and wraps
with dogpile the already bound-methods (from instantiated objects). It
turns out this isn't really needed and the solution will be to not add the
extra layer of wrapping into the SDK bits. I expect I can roll a patch for
that later today. The extra layer of wrapping was to bubble up an
.invalidate method, which strictly should have already existed when using
dogpile. I'll make sure to unroll all the potential issues and get SDK into
a sane place.

In my opinion dogpile.cache is doing the right thing and assuming it is in
charge of wrapping the methods. Wrapping (with a decorator) bound methods
is a weird bit of meta-programming I don't see as necessary to support.
With that said, this was a change in behavior.

I've been unable (need to find my hardware token) to login to github to
comment on the issue (will do this today) but I am going to comment much
the same as I have here on the mailing list.

Finally, I do think we should add the feedback loop to dogpile from
openstack as we lean on it pretty heavily. I believe the big projects to
catch are SDK/shade, Keystone, Keystone Middleware, and Oslo.Cache
(oslo.cache should cover everything but openstackSDK/shade). I might be
missing bits of infra as well in this list.

On Fri, Dec 14, 2018 at 6:55 AM Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2018-12-14 09:11:39 -0500 (-0500), Mike Bayer wrote:
> [...]
> > Are there folks here who would like to watch the dogpile.cache
> > github project (now at
> > https://github.com/sqlalchemy/dogpile.cache) as well as our gerrit
> > so that future changes can get some more review?
>
> Alternatively, zuul.openstack.org has the ability to test pull
> requests for GitHub repositories automatically and report back
> configured job results (basically acting as a third-party CI
> system). We already do this for Ansible, for example. If we can
> identify a good set of candidate jobs to run, is this something
> you'd be interested in?
> --
> Jeremy Stanley
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181214/95952217/attachment.html>


More information about the openstack-discuss mailing list