<div dir="ltr"><div dir="ltr">This is fixed with a quick added function wrapper before passing to dogpile's decorator/wrapper method(s) [0]. I have confirmed it has remedied the issue directly and locally, but have been unable to produce a full unit test yet.<div><br></div><div>[0] <a href="https://review.openstack.org/#/c/625370/">https://review.openstack.org/#/c/625370/</a></div><div><br></div><div>--Morgan</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 14, 2018 at 10:06 AM Mike Bayer <<a href="mailto:mike_mp@zzzcomputing.com">mike_mp@zzzcomputing.com</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 Fri, Dec 14, 2018 at 10:48 AM Morgan Fainberg<br>
<<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
I wasn't sure that the use of decorator instead of a homegrown was<br>
really going to be noticeable but I guess it is.  Nevertheless I did<br>
move from 0.6.x to 0.7.x which in my own projects means<br>
behaviorally-modifying change  (my versioning scheme is <the laws of<br>
physics have changed>.<major features with potential behavioral<br>
changes>.<non breaking bug fixes and small features>).<br>
<br>
<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> On Fri, Dec 14, 2018 at 6:55 AM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>> wrote:<br>
>><br>
>> 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>