[openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached
ayoung at redhat.com
Fri May 13 20:12:59 UTC 2016
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?
>>>> 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:
>> 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
More information about the OpenStack-dev