[openstack-dev] [all] Maintaining httplib2 python library
geguileo at redhat.com
Tue Mar 15 10:36:46 UTC 2016
On 14/03, Sean McGinnis wrote:
> On Mon, Mar 14, 2016 at 10:37:52AM -0400, Sean Dague wrote:
> > On 03/14/2016 10:24 AM, Ian Cordasco wrote:
> > >
> > >
> > > -----Original Message-----
> > > From: Davanum Srinivas <davanum at gmail.com>
> > > Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
> > > Date: March 14, 2016 at 09:18:50
> > > To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
> > > Subject: [openstack-dev] [all] Maintaining httplib2 python library
> > >
> > >> Team,
> > >>
> > >> fyi, http://bitworking.org/news/2016/03/an_update_on_httplib2
> > >>
> > >> We have httplib2 in our global requirements and lots of projects are
> > >> using it. Is there anyone willing to step up?
> > >
> > > Is it really worth our time to dedicate extra resources to that? Glance has been discussing (but it's been a low priority) to switing all our dependence on httplib2 to requests (and maybe urllib3 directly) as necessary.
> > >
> > > We have other tools and libraries we can use without taking over maintenance of yet another library.
> > >
> > > I think the better question than "Can people please maintain this for the community?" is "What benefits does httplib2 have over something that is actively maintained (and has been actively maintaiend) like urllib3, requests, etc.?"
> > >
> > > And then we can (and should) also ask "Why have we been using this? How much work do cores think it would be to remove this from our global requirements?"
> Cinder only has it in a new backup driver for Google Cloud Storage. The
> googleapiclient docs actually say to use httplib2 for one of the calls
> "or something that acts like it."
> I will see if we can switch this over to an appropriate duck type. I
> would much rather get rid of usage than unnecessarily keep a project on
> life support.
Looking at Google's api python client I see it has a dependency on
httplib2  but it looks like Sean's duck typing suggestion would work
in our case since we are not using batch http requests and Google's
library would mostly use httplib2 for constants. Although we would
still have an indirect dependency on httplib2.
If we really want to remove cinder's dependency from httplib2, indirect
or otherwise, we could switch to another Google cloud library, like
(shameless plug here) gcs-client  that uses requests instead of
httplib2 and which would not only be easy to replace it with, but has
also already been tested as a Google Cloud Backup driver in cinder .
> > +1.
> > Here is the non comprehensive list of usages based on what trees I
> > happen to have checked out (which is quite a few, but not all of
> > OpenStack for sure).
> > I think before deciding to take over ownership of an upstream lib (which
> > is a large commitment over space and time), we should figure out the
> > migration cost. All the uses in Tempest come from usage in Glance IIRC
> > (and dealing with chunked encoding).
> > Neutron seems to use it for a couple of proxies, but that seems like
> > requests/urllib3 might be sufficient.
> > In Horizon it's only used for a couple of tests.
> > EC2 uses it as a proxy client to the Nova metadata service. Again, I
> > can't imagine that requests wouldn't be sufficient.
> > Trove doesn't seem to actually use it (though it's listed), though maybe
> > wsgi_intercept uses it directly?
> > run_tests.py:from wsgi_intercept.httplib2_intercept import install as
> > wsgi_install
> > python-muranoclient lists it as a requirement, there is no reference in
> > the source tree for it.
> > I suspect Glance is really the lynchpin here (as it actually does some
> > low level stuff with it). If there can be a Glance plan to get off of
> > it, the rest can follow pretty easily.
> > -Sean
> > --
> > Sean Dague
> > http://dague.net
> > __________________________________________________________________________
> > 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev