<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 13, 2016 at 1:12 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 05/13/2016 12:52 PM, Monty Taylor wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/13/2016 11:38 AM, Eric Larson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Monty Taylor writes:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/13/2016 08:23 AM, Mehdi Abaakouk wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, May 13, 2016 at 02:58:08PM +0200, Julien Danjou wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What's wrong with pymemcache, that we picked for tooz and are using<br>
for 2 years now?<br>
<br>
  <a href="https://github.com/pinterest/pymemcache" rel="noreferrer" target="_blank">https://github.com/pinterest/pymemcache</a><br>
</blockquote>
Looks like a good alternative.<br>
</blockquote>
Honestly, nobody should be using pymemcache or python-memcached or<br>
pylibmc for anything caching related in OpenStack. People should be<br>
using oslo.cache - however, if that needs work before it's usable,<br>
people should be using dogpile.cache, which is what oslo.cache uses on<br>
the backend.<br>
<br>
dogpile is pluggable, so it means that the backend used for caching<br>
can be chosen in a much broader manner. As morgan mentions elsewhere,<br>
that means that people who want to use a different memcache library<br>
just need to write a dogpile driver.<br>
<br>
Please don't anybody directly use memcache libraries for caching in<br>
OpenStack. Please.<br>
<br>
</blockquote>
Using dogpile doesn't remove the decision of what caching backend is<br>
used. Dogpile has support (I think) for all the libraries mentioned here:<br>
<br>
<a href="https://bitbucket.org/zzzeek/dogpile.cache/src/87965ada186f9b3a4eb7ff033a2e31437d5e9bc6/dogpile/cache/backends/memcached.py" rel="noreferrer" target="_blank">https://bitbucket.org/zzzeek/dogpile.cache/src/87965ada186f9b3a4eb7ff033a2e31437d5e9bc6/dogpile/cache/backends/memcached.py</a><br>
<br>
<br>
Oslo cache would need to be the one making decision as to what backend<br>
is used if we need to have something consistent.<br>
</blockquote>
I do not understand why oslo.cache would make a backend decision. It's a<br>
config-driven thing. I could see oslo.cache having a _default_ ... but<br>
having oslo.cache use dogpile.cache and then remove the ability for a<br>
deployer to chose which caching backend dogpile uses seems more than<br>
passing strange to me.<br>
</blockquote>
<br></div></div>
With oslo cache, you say "I want memcache" and Oslo picks the driver.  Standardizes the implementation within OpenStack.<div><div><br></div></div></blockquote><div><br></div><div>You can also specify pylibmc or BMemcached, or Redis, or <my cool driver that lives in entry point XXXX> 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. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With that said, it is important that we understand what projects have<br>
specific requirements or have experienced issues, otherwise there is a<br>
good chance teams will hit an issue down the line and have to work<br>
around it.<br>
</blockquote>
Yup. Totally agree. I certainly don't want to imply that there aren't<br>
issues with memcache libs nor that they shouldn't be fixed. Merely<br>
trying to point out that individual projects programming to the<br>
interface of any of the libs is a thing that should be fixed.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>