Open Stack

On May 13, 2016 05:32, "Kiall Mac Innes" <kiall at macinnes.ie> wrote:
>
> Hey Dims,
>
> From what I remember, oslo.cache seemed unnecessarily complex to use
> vs memcache's simplicity, and didn't have any usage docs[1] to help folks
> get started using it.
>
> I can see there is some docs under the module index, but at a glance they
> seem somewhat disconnected and incomplete.
>
> Are there any complete examples of it's use available for us to compare
> against python-memcached and pylibmc etc?
>
> If there comparable functionality and perf wise, I don't see a reason why
> projects wouldn't switch. I'll certainly make the effort for Designate if
it
> looks like the right thing to do.
>
> Thanks,
> Kiall
>
> [1]: http://docs.openstack.org/developer/oslo.cache/usage.html
>
>
> On 13/05/16 12:35, Davanum Srinivas wrote:
> > Steve,
> >
> > Couple of points:
> >
> > * We can add pylibmc to g-r and phase out python-memcached over a time
period.
> > * If folks are using python-memcached, we should switch then over to
> > oslo.cache, then only oslo.cache will reference either
> > python-memcached or pylibmc which will make the situation easier to
> > handle.
> >
> > Thanks,
> > Dims
> >
> > On Fri, May 13, 2016 at 4:14 AM, Steve Martinelli
> > <s.martinelli at gmail.com> wrote:
> >> /me gets the ball rolling
> >>
> >> Just when python3 support for keystone was looking like a reality,
we've hit
> >> another snag. Apparently there are several issues with
python-memcached in
> >> py3, putting it simply: it loads, but doesn't actually work. I've
included
> >> projects in the subject line that use python-memcached (based on
codesearch)
> >>
> >> Enter pylibmc; apparently it is (almost?) a drop-in replacement,
performs
> >> better, and is more actively maintained.
> >>
> >> - Has anyone had success using python-memcached in py3?
> >> - Is anyone interested in using pylibmc in their project instead of
> >> python-memcached?
> >> - Will buy-in from all projects be necessary to proceed for any single
> >> project?
> >>
> >> Open issues like this:
> >> https://github.com/linsomniac/python-memcached/issues/94 make me sad.
> >>
> >> stevemar
> >>
> >>
__________________________________________________________________________
> >> 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

Oslo.cache has a higher barrier to entry, but that is based on how dogpile
works and how keystone consumed it initially to be "pluggable".

We should make Oslo.cache better. It has some built in features because of
dogpile that are nice and doesn't strictly lock to memcache (but provides a
simple memcache-like interface for many backends) once configured. It also
allows for easier transitions between the libraries if they are needed (a
dogpile driver is not hard to make).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160513/361b4c83/attachment.html>