Open Stack

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.