For the future ============== IMHO, we shouldn't be pulling in duplicate dependencies when we can control it. Since tooz is part of stackforge, it's somewhat part of OpenStack. We should strive to make all OpenStack projects use one memcached client.
That being said, a quick Google search indicates that pymemcache has some benefits over python-memcache, the latter not being python 3 compatible. Additionally, pymemcache was written by the Pinterest people, so I'd imaging it stands up fairly well under stress. Perhaps we should consider porting the existing OpenStack projects from python-memcache to pymemcache. In the future, though, we need to make sure to avoid getting into a situation like this. For the present =============== Probably, we'll just have to get pymemcache packaged for Fedora in some form. Like you said, it can be bundled in RDO. If you're not using RDO I think it's safe to just tell people to install it from other sources (pip install) until we can get the package into Fedora. Best Regards, Solly Ross ----- Original Message ----- > From: "Matt Riedemann" <mrie...@linux.vnet.ibm.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Sent: Tuesday, September 9, 2014 4:30:02 PM > Subject: [openstack-dev] global-reqs on tooz pulls in worrisome transitive > dep > > It took me a while to untangle this so prepare for links. :) > > I noticed this change [1] today for global-requirements to require tooz > [2] for a ceilometer blueprint [3]. > > The sad part is that tooz requires pymemcache [4] which is, from what I > can tell, a memcached client that is not the same as python-memcached [5]. > > Note that python-memcached is listed in global-requirements already [6]. > > The problem I have with this is it doesn't appear that RHEL/Fedora > package pymemcache (they do package python-memcached). I see that > openSUSE builds separate packages for each. It looks like Ubuntu also > has separate packages. > > My question is, is this a problem? I'm assuming RDO will just have to > package python-pymemcache themselves but what about people not using RDO > (SOL? Don't care? Other?). > > Reverting the requirements change would probably mean reverting the > ceilometer blueprint (or getting a version of tooz out that works with > python-memcached which is probably too late for that right now). Given > the point in the schedule that seems pretty drastic. > > Maybe I'm making more of this than it's worth but wanted to bring it up > in case anyone else has concerns. > > [1] https://review.openstack.org/#/c/93443/ > [2] https://github.com/stackforge/tooz/blob/master/requirements.txt#L6 > [3] > http://specs.openstack.org/openstack/ceilometer-specs/specs/juno/central-agent-partitioning.html > [4] https://pypi.python.org/pypi/pymemcache > [5] https://pypi.python.org/pypi/python-memcached/ > [6] > https://github.com/openstack/requirements/blob/master/global-requirements.txt#L108 > > -- > > Thanks, > > Matt Riedemann > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
