<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 14, 2018 at 6:55 AM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2018-12-14 09:11:39 -0500 (-0500), Mike Bayer wrote:<br>
[...]<br>
> Are there folks here who would like to watch the dogpile.cache<br>
> github project (now at<br>
> <a href="https://github.com/sqlalchemy/dogpile.cache" rel="noreferrer" target="_blank">https://github.com/sqlalchemy/dogpile.cache</a>) as well as our gerrit<br>
> so that future changes can get some more review?<br>
<br>
Alternatively, <a href="http://zuul.openstack.org" rel="noreferrer" target="_blank">zuul.openstack.org</a> has the ability to test pull<br>
requests for GitHub repositories automatically and report back<br>
configured job results (basically acting as a third-party CI<br>
system). We already do this for Ansible, for example. If we can<br>
identify a good set of candidate jobs to run, is this something<br>
you'd be interested in?<br>
-- <br>
Jeremy Stanley<br>
</blockquote></div>