Open Stack

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