Open Stack

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.

[0] https://review.openstack.org/#/c/625370/

--Morgan

On Fri, Dec 14, 2018 at 10:06 AM Mike Bayer <mike_mp at zzzcomputing.com>
wrote:

> On Fri, Dec 14, 2018 at 10:48 AM Morgan Fainberg
> <morgan.fainberg at gmail.com> wrote:
> >
> > 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 wasn't sure that the use of decorator instead of a homegrown was
> really going to be noticeable but I guess it is.  Nevertheless I did
> move from 0.6.x to 0.7.x which in my own projects means
> behaviorally-modifying change  (my versioning scheme is <the laws of
> physics have changed>.<major features with potential behavioral
> changes>.<non breaking bug fixes and small features>).
>
>
> >
> > 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/856080e8/attachment.html>