Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Morgan Fainberg]

On Fri, May 13, 2016 at 1:12 PM, Adam Young  wrote:

> On 05/13/2016 12:52 PM, Monty Taylor wrote:
>
>> On 05/13/2016 11:38 AM, Eric Larson wrote:
>>
>>> Monty Taylor writes:
>>>
>>> On 05/13/2016 08:23 AM, Mehdi Abaakouk wrote:

> On Fri, May 13, 2016 at 02:58:08PM +0200, Julien Danjou wrote:
>
>> What's wrong with pymemcache, that we picked for tooz and are using
>> for 2 years now?
>>
>>   https://github.com/pinterest/pymemcache
>>
> Looks like a good alternative.
>
 Honestly, nobody should be using pymemcache or python-memcached or
 pylibmc for anything caching related in OpenStack. People should be
 using oslo.cache - however, if that needs work before it's usable,
 people should be using dogpile.cache, which is what oslo.cache uses on
 the backend.

 dogpile is pluggable, so it means that the backend used for caching
 can be chosen in a much broader manner. As morgan mentions elsewhere,
 that means that people who want to use a different memcache library
 just need to write a dogpile driver.

 Please don't anybody directly use memcache libraries for caching in
 OpenStack. Please.

 Using dogpile doesn't remove the decision of what caching backend is
>>> used. Dogpile has support (I think) for all the libraries mentioned here:
>>>
>>>
>>> https://bitbucket.org/zzzeek/dogpile.cache/src/87965ada186f9b3a4eb7ff033a2e31437d5e9bc6/dogpile/cache/backends/memcached.py
>>>
>>>
>>> Oslo cache would need to be the one making decision as to what backend
>>> is used if we need to have something consistent.
>>>
>> I do not understand why oslo.cache would make a backend decision. It's a
>> config-driven thing. I could see oslo.cache having a _default_ ... but
>> having oslo.cache use dogpile.cache and then remove the ability for a
>> deployer to chose which caching backend dogpile uses seems more than
>> passing strange to me.
>>
>
> With oslo cache, you say "I want memcache" and Oslo picks the driver.
> Standardizes the implementation within OpenStack.
>
>
You can also specify pylibmc or BMemcached, or Redis, or  as well when issuing the .configure() to
the dogpile.cache region. The default oslo.cache uses is python-memcached,
but that could be fixed easily.

>
>
>> With that said, it is important that we understand what projects have
>>> specific requirements or have experienced issues, otherwise there is a
>>> good chance teams will hit an issue down the line and have to work
>>> around it.
>>>
>> Yup. Totally agree. I certainly don't want to imply that there aren't
>> issues with memcache libs nor that they shouldn't be fixed. Merely
>> trying to point out that individual projects programming to the
>> interface of any of the libs is a thing that should be fixed.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Adam Young]

On 05/13/2016 12:52 PM, Monty Taylor wrote:

On 05/13/2016 11:38 AM, Eric Larson wrote:

Monty Taylor writes:


On 05/13/2016 08:23 AM, Mehdi Abaakouk wrote:

On Fri, May 13, 2016 at 02:58:08PM +0200, Julien Danjou wrote:

What's wrong with pymemcache, that we picked for tooz and are using
for 2 years now?

  https://github.com/pinterest/pymemcache

Looks like a good alternative.

Honestly, nobody should be using pymemcache or python-memcached or
pylibmc for anything caching related in OpenStack. People should be
using oslo.cache - however, if that needs work before it's usable,
people should be using dogpile.cache, which is what oslo.cache uses on
the backend.

dogpile is pluggable, so it means that the backend used for caching
can be chosen in a much broader manner. As morgan mentions elsewhere,
that means that people who want to use a different memcache library
just need to write a dogpile driver.

Please don't anybody directly use memcache libraries for caching in
OpenStack. Please.


Using dogpile doesn't remove the decision of what caching backend is
used. Dogpile has support (I think) for all the libraries mentioned here:

https://bitbucket.org/zzzeek/dogpile.cache/src/87965ada186f9b3a4eb7ff033a2e31437d5e9bc6/dogpile/cache/backends/memcached.py


Oslo cache would need to be the one making decision as to what backend
is used if we need to have something consistent.

I do not understand why oslo.cache would make a backend decision. It's a
config-driven thing. I could see oslo.cache having a _default_ ... but
having oslo.cache use dogpile.cache and then remove the ability for a
deployer to chose which caching backend dogpile uses seems more than
passing strange to me.


With oslo cache, you say "I want memcache" and Oslo picks the driver.  
Standardizes the implementation within OpenStack.





With that said, it is important that we understand what projects have
specific requirements or have experienced issues, otherwise there is a
good chance teams will hit an issue down the line and have to work
around it.

Yup. Totally agree. I certainly don't want to imply that there aren't
issues with memcache libs nor that they shouldn't be fixed. Merely
trying to point out that individual projects programming to the
interface of any of the libs is a thing that should be fixed.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Monty Taylor]

On 05/13/2016 11:38 AM, Eric Larson wrote:
> 
> Monty Taylor writes:
> 
>> On 05/13/2016 08:23 AM, Mehdi Abaakouk wrote:
>>> On Fri, May 13, 2016 at 02:58:08PM +0200, Julien Danjou wrote:
 What's wrong with pymemcache, that we picked for tooz and are using
 for 2 years now?

  https://github.com/pinterest/pymemcache
>>>
>>> Looks like a good alternative.
>>
>> Honestly, nobody should be using pymemcache or python-memcached or
>> pylibmc for anything caching related in OpenStack. People should be
>> using oslo.cache - however, if that needs work before it's usable,
>> people should be using dogpile.cache, which is what oslo.cache uses on
>> the backend.
>>
>> dogpile is pluggable, so it means that the backend used for caching
>> can be chosen in a much broader manner. As morgan mentions elsewhere,
>> that means that people who want to use a different memcache library
>> just need to write a dogpile driver.
>>
>> Please don't anybody directly use memcache libraries for caching in
>> OpenStack. Please.
>>
> 
> Using dogpile doesn't remove the decision of what caching backend is
> used. Dogpile has support (I think) for all the libraries mentioned here:
> 
> https://bitbucket.org/zzzeek/dogpile.cache/src/87965ada186f9b3a4eb7ff033a2e31437d5e9bc6/dogpile/cache/backends/memcached.py
> 
> 
> Oslo cache would need to be the one making decision as to what backend
> is used if we need to have something consistent.

I do not understand why oslo.cache would make a backend decision. It's a
config-driven thing. I could see oslo.cache having a _default_ ... but
having oslo.cache use dogpile.cache and then remove the ability for a
deployer to chose which caching backend dogpile uses seems more than
passing strange to me.

> With that said, it is important that we understand what projects have
> specific requirements or have experienced issues, otherwise there is a
> good chance teams will hit an issue down the line and have to work
> around it.

Yup. Totally agree. I certainly don't want to imply that there aren't
issues with memcache libs nor that they shouldn't be fixed. Merely
trying to point out that individual projects programming to the
interface of any of the libs is a thing that should be fixed.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Eric Larson]

Monty Taylor writes:


On 05/13/2016 08:23 AM, Mehdi Abaakouk wrote:

On Fri, May 13, 2016 at 02:58:08PM +0200, Julien Danjou wrote:
What's wrong with pymemcache, that we picked for tooz and are 
using for 2 years now?


 https://github.com/pinterest/pymemcache


Looks like a good alternative.


Honestly, nobody should be using pymemcache or python-memcached 
or pylibmc for anything caching related in OpenStack. People 
should be using oslo.cache - however, if that needs work before 
it's usable, people should be using dogpile.cache, which is what 
oslo.cache uses on the backend.


dogpile is pluggable, so it means that the backend used for 
caching can be chosen in a much broader manner. As morgan 
mentions elsewhere, that means that people who want to use a 
different memcache library just need to write a dogpile driver.


Please don't anybody directly use memcache libraries for caching 
in OpenStack. Please.




Using dogpile doesn't remove the decision of what caching backend 
is used. Dogpile has support (I think) for all the libraries 
mentioned here:


https://bitbucket.org/zzzeek/dogpile.cache/src/87965ada186f9b3a4eb7ff033a2e31437d5e9bc6/dogpile/cache/backends/memcached.py

Oslo cache would need to be the one making decision as to what 
backend is used if we need to have something consistent.


With that said, it is important that we understand what projects 
have specific requirements or have experienced issues, otherwise 
there is a good chance teams will hit an issue down the line and 
have to work around it.


Eric



Monty


__ 
OpenStack Development Mailing List (not for usage questions) 
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--

Eric Larson | eric.lar...@rackspace.com Software Developer 
| Cloud DNS | OpenStack Designate Rackspace Hosting   | Austin, 
Texas


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Monty Taylor]

On 05/13/2016 08:23 AM, Mehdi Abaakouk wrote:
> On Fri, May 13, 2016 at 02:58:08PM +0200, Julien Danjou wrote:
>> What's wrong with pymemcache, that we picked for tooz and are using for
>> 2 years now?
>>
>>  https://github.com/pinterest/pymemcache
> 
> Looks like a good alternative.

Honestly, nobody should be using pymemcache or python-memcached or
pylibmc for anything caching related in OpenStack. People should be
using oslo.cache - however, if that needs work before it's usable,
people should be using dogpile.cache, which is what oslo.cache uses on
the backend.

dogpile is pluggable, so it means that the backend used for caching can
be chosen in a much broader manner. As morgan mentions elsewhere, that
means that people who want to use a different memcache library just need
to write a dogpile driver.

Please don't anybody directly use memcache libraries for caching in
OpenStack. Please.

Monty


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Morgan Fainberg]

On Fri, May 13, 2016 at 6:23 AM, Mehdi Abaakouk  wrote:

> On Fri, May 13, 2016 at 02:58:08PM +0200, Julien Danjou wrote:
>
>> What's wrong with pymemcache, that we picked for tooz and are using for
>> 2 years now?
>>
>>  https://github.com/pinterest/pymemcache
>>
>
> Looks like a good alternative.
>
> --
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

pymemcache is not drop-in replacement for python-memcached, but the cost to
wire it up to dogpile is effectively a 1-time cost and would need to be
done in general for the way keystone / keystonemiddleware works. It isn't
unreasonable to go with this option.

pymemcache used to have glaring holes in capabilities, but it seems it is
mostly up to par now.

--Morgan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[John Dickinson]

On 13 May 2016, at 1:14, Steve Martinelli 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


In Swift, we've got our own memcache client[1] to get around some of the issues 
that were present in python-memcached at the time we needed it. Those issues 
may (or may not) be resolved now, but basically we've been very happy for years 
now with our own memcache client. It's drop-in compatible with python-memcached.

[1] https://github.com/openstack/swift/blob/master/swift/common/memcached.py 
(note the docstring at the top)


--John





signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Mehdi Abaakouk]

On Fri, May 13, 2016 at 02:58:08PM +0200, Julien Danjou wrote:

What's wrong with pymemcache, that we picked for tooz and are using for
2 years now?

 https://github.com/pinterest/pymemcache


Looks like a good alternative.

--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Julien Danjou]

On Fri, May 13 2016, Steve Martinelli 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)

What's wrong with pymemcache, that we picked for tooz and are using for
2 years now?

  https://github.com/pinterest/pymemcache

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Morgan Fainberg]

On May 13, 2016 05:32, "Kiall Mac Innes"  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
> >  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-requ...@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-requ...@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).
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Kiall Mac Innes]

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
>  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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Morgan Fainberg]

On May 13, 2016 05:25, "Mehdi Abaakouk"  wrote:
>>>
>>> - Is anyone interested in using pylibmc in their project instead of
>>> python-memcached?
>
>
> This is not a real drop-in replacement, pylibmc.Client is not threadsafe
> like python-memcached [1]. Aos it's written in C, it shouldn't be a
> problem for keystone because you don't use eventlet anymore, but for
> project that still use eventlet no greenlet switch will occurs during
> memcached IO.
>
> [1]
http://sendapatch.se/projects/pylibmc/misc.html#differences-from-python-memcached
>
> --
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

FYI - Python-memcached is not really greenlet safe under load. We found
that it explicitly uses thread.local which means that enough connections
coming into a service that means heavily on memcache can cause the memcache
server to end up with a ton of open connections/max out TCP connection
limits.

This had to be worked around in keystone under eventlet. Luckily it hasn't
hit other projects too hard. This move should consider that design issue as
well (regardless of the final choice)

--Morgan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Mehdi Abaakouk]

- Is anyone interested in using pylibmc in their project instead of
python-memcached?


This is not a real drop-in replacement, pylibmc.Client is not threadsafe
like python-memcached [1]. Aos it's written in C, it shouldn't be a
problem for keystone because you don't use eventlet anymore, but for
project that still use eventlet no greenlet switch will occurs during
memcached IO.

[1] 
http://sendapatch.se/projects/pylibmc/misc.html#differences-from-python-memcached

--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Morgan Fainberg]

On May 13, 2016 04:36, "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
>  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-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Another option is we could fork Python-Memcached and maintain it ourselves
(I would prefer to use pylibmc). But for a strictly pure Python
implementation it might make sense to do this.

Pymemcache is also another option, but was missing basic features last time
I looked / behaved significantly different (no mulit server support, etc).
We should revisit looking at pymemcache as well if we are looking at
pylibmc.

For the record, Python-memcached has at best been sporadically maintained
for the last year. This topic has come up a few times.

--Morgan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Davanum Srinivas]

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
 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

[Steve Martinelli]

/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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev