Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached
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
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
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
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
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
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
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
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
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
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
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
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
- 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
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
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