Re: [openstack-dev] [all] Maintaining httplib2 python library

[Matthew Treinish]

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 <dava...@gmail.com>
> > Reply: OpenStack Development Mailing List (not for usage questions) 
> > <openstack-dev@lists.openstack.org>
> > Date: March 14, 2016 at 09:18:50
> > To: OpenStack Development Mailing List (not for usage questions) 
> > <openstack-dev@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[1]. 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?"
> 
> +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).

No, that's actually the one use case that httplib2 isn't used for in tempest.
The code to deal with chunking based on glanceclient uses httplib. Tempest uses
httplib2 for all it's API traffic. (except when uploading or downloading images
from glance) That being said Jordan Pittier has a WIP patch up switching the
tempest usage from httplib2 to urllib3:

https://review.openstack.org/#/c/295900/

> 
> 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
> 


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] [all] Maintaining httplib2 python library

[Davanum Srinivas]

Ian, Chris,

You should see invites to join the httplib2 org on github.

Thanks,
Dims

On Fri, Mar 18, 2016 at 3:04 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>
>
> -Original Message-
> From: Cory Benfield <c...@lukasa.co.uk>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: March 18, 2016 at 13:06:02
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [all] Maintaining httplib2 python library
>
>>
>> > On 18 Mar 2016, at 17:05, Doug Wiegley wrote:
>> >> On Mar 18, 2016, at 8:31 AM, Cory Benfield wrote:
>> >>
>> >> Getting requests to talk over a Unix domain socket is not particularly 
>> >> tricky, and
>> there are third-party libraries that hook into requests appropriately to 
>> make that
>> happen. For example, the requests-unixsocket module exists that can do the 
>> appropriate
>> things.
>> >
>> > That’s the module that I was eyeing, but we’re just trading one dependency 
>> > for another.
>> Is there something about httplib2 maintenance in particular that makes us 
>> want that
>> gone?
>> >
>> > doug
>>
>> The original message in this thread was about the fact that httplib2 is 
>> currently unmaintained
>> and looking for new maintainers. I believe that was the impetus for the 
>> discussion.
>
> Unrelatedly, the author hasn't responded to either email or twitter. I've 
> offered to help keep it on life support but they've not responded. So perhaps 
> they're not interested in adding maintainers after all.
>
> Either way, it's likely a dying project and not one we should hold onto.
>
> But I mean, ignoring that it's dying, it's a great piece of software.
>
> --
> Ian Cordasco
>
>
> __
> 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

Re: [openstack-dev] [all] Maintaining httplib2 python library

[Ian Cordasco]

 

-Original Message-
From: Cory Benfield <c...@lukasa.co.uk>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: March 18, 2016 at 13:06:02
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Maintaining httplib2 python library

>  
> > On 18 Mar 2016, at 17:05, Doug Wiegley wrote:
> >> On Mar 18, 2016, at 8:31 AM, Cory Benfield wrote:
> >>
> >> Getting requests to talk over a Unix domain socket is not particularly 
> >> tricky, and  
> there are third-party libraries that hook into requests appropriately to make 
> that  
> happen. For example, the requests-unixsocket module exists that can do the 
> appropriate  
> things.
> >
> > That’s the module that I was eyeing, but we’re just trading one dependency 
> > for another.  
> Is there something about httplib2 maintenance in particular that makes us 
> want that  
> gone?
> >
> > doug
>  
> The original message in this thread was about the fact that httplib2 is 
> currently unmaintained  
> and looking for new maintainers. I believe that was the impetus for the 
> discussion.

Unrelatedly, the author hasn't responded to either email or twitter. I've 
offered to help keep it on life support but they've not responded. So perhaps 
they're not interested in adding maintainers after all.

Either way, it's likely a dying project and not one we should hold onto.

But I mean, ignoring that it's dying, it's a great piece of software.

--  
Ian Cordasco


__
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] [all] Maintaining httplib2 python library

[Cory Benfield]

> On 18 Mar 2016, at 17:05, Doug Wiegley  wrote:
>> On Mar 18, 2016, at 8:31 AM, Cory Benfield  wrote:
>> 
>> Getting requests to talk over a Unix domain socket is not particularly 
>> tricky, and there are third-party libraries that hook into requests 
>> appropriately to make that happen. For example, the requests-unixsocket 
>> module exists that can do the appropriate things.
> 
> That’s the module that I was eyeing, but we’re just trading one dependency 
> for another. Is there something about httplib2 maintenance in particular that 
> makes us want that gone?
> 
> doug

The original message in this thread was about the fact that httplib2 is 
currently unmaintained and looking for new maintainers. I believe that was the 
impetus for the discussion.

Cory


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [all] Maintaining httplib2 python library

[Joshua Harlow]

On 03/18/2016 02:34 AM, Thierry Carrez wrote:

Thomas Goirand wrote:

On 03/14/2016 03:28 PM, Davanum Srinivas wrote:

Ian,

+1 to get rid of that dependency if possible.


+1 for any action aiming toward removing *any* dependency.

We don't have enough of such actions, and we have a way too many
dependencies, with many duplicate functionalities too. Just to name a
few:
- pecan vs falcon
- oslo.concurrency vs lockfile
- nose vs testr vs pytest
- pymemcache vs memcached
- you-name-it...

And this isn't even motivated by the fact I maintain lots of packages, I
don't maintain httplib2 for example, so I'm not impacted much,
especially by this kind of package that don't upgrade often.


Converging dependencies is a bit of a thankless debt reduction job: you
have to push changes in a lot of projects, and those are rarely seen as
a priority. It's a bit like pushing for Python 3 compatibility... you
need to find someone caring enough about it to persist in pushing those
changes, otherwise it just doesn't happen.

We could have a squad of "convergers" that would define a very small
list of targets every cycle and push that through.



+1 for the above. Have a few people that would come and help here on 
these kinds of tasks and overtime hopefully the list of targets shrinks 
(although likely never to zero).


-Josh

__
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] [all] Maintaining httplib2 python library

[Cory Benfield]

> On 18 Mar 2016, at 13:57, Brian Haley  wrote:
> 
> On 03/17/2016 06:04 PM, Doug Wiegley wrote:
 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.
>>> 
>>> The Neutron team should talk to Cory Benfield (CC'd) and myself more about 
>>> this if they run into problems. requests and urllib3 are a little limited 
>>> with respect to proxies due to limitations in httplib itself.
>>> 
>>> Both of us might be able to dedicate time during the day to fix this if 
>>> Neutron/OpenStack have specific requirements that requests is not currently 
>>> capable of supporting.
>> 
>> Looks like neutron is using it to do HTTP requests via unix domain sockets. 
>> Unless I’m missing something, requests doesn’t support that directly. There 
>> are a couple of other libs that do, or we could monkey patch the socket. Or 
>> modify the agents to use localhost.
> 
> We have to use Unix domain sockets in the metadata proxy because it's running 
> in a namespace, so can't use localhost to talk to the agent.  But we could 
> use some other library of course.
> 

Getting requests to talk over a Unix domain socket is not particularly tricky, 
and there are third-party libraries that hook into requests appropriately to 
make that happen. For example, the requests-unixsocket module exists that can 
do the appropriate things.

Cory



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [all] Maintaining httplib2 python library

[Julien Danjou]

On Thu, Mar 17 2016, Thomas Goirand wrote:

> We don't have enough of such actions, and we have a way too many
> dependencies, with many duplicate functionalities too. Just to name a few:
> - oslo.concurrency vs lockfile

You made me check, but this is not true anymore. Lockfile is not used
anywhere, except in a few (not-really|un)maintained projects.

-- 
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] [all] Maintaining httplib2 python library

[Doug Wiegley]

> On Mar 18, 2016, at 8:31 AM, Cory Benfield  wrote:
> 
>> 
>> On 18 Mar 2016, at 13:57, Brian Haley  wrote:
>> 
>> On 03/17/2016 06:04 PM, Doug Wiegley wrote:
> 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.
 
 The Neutron team should talk to Cory Benfield (CC'd) and myself more about 
 this if they run into problems. requests and urllib3 are a little limited 
 with respect to proxies due to limitations in httplib itself.
 
 Both of us might be able to dedicate time during the day to fix this if 
 Neutron/OpenStack have specific requirements that requests is not 
 currently capable of supporting.
>>> 
>>> Looks like neutron is using it to do HTTP requests via unix domain sockets. 
>>> Unless I’m missing something, requests doesn’t support that directly. There 
>>> are a couple of other libs that do, or we could monkey patch the socket. Or 
>>> modify the agents to use localhost.
>> 
>> We have to use Unix domain sockets in the metadata proxy because it's 
>> running in a namespace, so can't use localhost to talk to the agent.  But we 
>> could use some other library of course.
>> 
> 
> Getting requests to talk over a Unix domain socket is not particularly 
> tricky, and there are third-party libraries that hook into requests 
> appropriately to make that happen. For example, the requests-unixsocket 
> module exists that can do the appropriate things.

That’s the module that I was eyeing, but we’re just trading one dependency for 
another. Is there something about httplib2 maintenance in particular that makes 
us want that gone?

doug


> 
> Cory
> 
> __
> 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] [all] Maintaining httplib2 python library

[David Lyle]

On Mar 14, 2016 11:32 AM, "Sean McGinnis" <sean.mcgin...@gmx.com> 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 <dava...@gmail.com>
> > > Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> > > Date: March 14, 2016 at 09:18:50
> > > To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@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[1]. 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.
>
> >
> > +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.
>

Horizon only has some out of date test code framework using httplib2. I
will remove shortly.



> >
> > 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
> >
> >
>

David
__
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] [all] Maintaining httplib2 python library

[Thierry Carrez]

Thomas Goirand wrote:

On 03/14/2016 03:28 PM, Davanum Srinivas wrote:

Ian,

+1 to get rid of that dependency if possible.


+1 for any action aiming toward removing *any* dependency.

We don't have enough of such actions, and we have a way too many
dependencies, with many duplicate functionalities too. Just to name a few:
- pecan vs falcon
- oslo.concurrency vs lockfile
- nose vs testr vs pytest
- pymemcache vs memcached
- you-name-it...

And this isn't even motivated by the fact I maintain lots of packages, I
don't maintain httplib2 for example, so I'm not impacted much,
especially by this kind of package that don't upgrade often.


Converging dependencies is a bit of a thankless debt reduction job: you 
have to push changes in a lot of projects, and those are rarely seen as 
a priority. It's a bit like pushing for Python 3 compatibility... you 
need to find someone caring enough about it to persist in pushing those 
changes, otherwise it just doesn't happen.


We could have a squad of "convergers" that would define a very small 
list of targets every cycle and push that through.


--
Thierry Carrez (ttx)

__
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] [all] Maintaining httplib2 python library

[Chris Dent]

On Mon, 14 Mar 2016, Chris Dent wrote:


wsgi-intercept (I maintain that) can use httplib2, http.lib or
requests (and if you go back a few versions even more) so those tests
could be updated to use requests and still use wsgi-intercept if that
was desired.


I've just released a version of wsgi-intercept (1.2.0 and beyond)
which has explicit support for urllib3:
https://pypi.python.org/pypi/wsgi_intercept


[1] If gabbi were to switch it wouldn't be to requests but probably
urllib3 because the reason httplib2 was chosen is because it does
very little for you and makes few guesses. Requests on the other
hand... However there are no immediate plans to make any changes.


Since the winds of change and dependency limiting are blowing,
I've started a branch in gabbi to switch urllib3:

   https://github.com/cdent/gabbi/pull/121

The proved to be relatively straightforward. What I needed was a
minor facade that translated the httplib2.Http.request method
arguments into appropriate ones for urllib3.PoolManager.request and
then transformed the response object into a dict of headers + status
and a content containing response.data.

If you have a look at the Http() class in gabbi/httpclient.py in
the diff of the pull request linked above it's no big deal. I
suspect it can be simplified and made more straightforward but
what's there gets the tests passing.

Happy to help out or answer questions if somebody thinks that since
I've been there I might be able to.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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] [all] Maintaining httplib2 python library

[Thomas Goirand]

On 03/14/2016 03:28 PM, Davanum Srinivas wrote:
> Ian,
> 
> +1 to get rid of that dependency if possible.

+1 for any action aiming toward removing *any* dependency.

We don't have enough of such actions, and we have a way too many
dependencies, with many duplicate functionalities too. Just to name a few:
- pecan vs falcon
- oslo.concurrency vs lockfile
- nose vs testr vs pytest
- pymemcache vs memcached
- you-name-it...

And this isn't even motivated by the fact I maintain lots of packages, I
don't maintain httplib2 for example, so I'm not impacted much,
especially by this kind of package that don't upgrade often.

Thomas Goirand (zigo)


__
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] [all] Maintaining httplib2 python library

[Thomas Goirand]

On 03/18/2016 09:31 AM, Julien Danjou wrote:
> On Thu, Mar 17 2016, Thomas Goirand wrote:
> 
>> We don't have enough of such actions, and we have a way too many
>> dependencies, with many duplicate functionalities too. Just to name a few:
>> - oslo.concurrency vs lockfile
> 
> You made me check, but this is not true anymore. Lockfile is not used
> anywhere, except in a few (not-really|un)maintained projects.

Good news!


__
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] [all] Maintaining httplib2 python library

[Doug Wiegley]

> On Mar 14, 2016, at 8:51 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
> 
> -Original Message-
> From: Sean Dague <s...@dague.net>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: March 14, 2016 at 09:41:02
> To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [all] Maintaining httplib2 python library
> 
>> On 03/14/2016 10:24 AM, Ian Cordasco wrote:
>>> 
>>> 
>>> -Original Message-
>>> From: Davanum Srinivas  
>>> Reply: OpenStack Development Mailing List (not for usage questions)  
>>> Date: March 14, 2016 at 09:18:50
>>> To: OpenStack Development Mailing List (not for usage questions)  
>>> 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[1]. 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?"
>> 
>> +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.
> 
> The Neutron team should talk to Cory Benfield (CC'd) and myself more about 
> this if they run into problems. requests and urllib3 are a little limited 
> with respect to proxies due to limitations in httplib itself.
> 
> Both of us might be able to dedicate time during the day to fix this if 
> Neutron/OpenStack have specific requirements that requests is not currently 
> capable of supporting.

Looks like neutron is using it to do HTTP requests via unix domain sockets. 
Unless I’m missing something, requests doesn’t support that directly. There are 
a couple of other libs that do, or we could monkey patch the socket. Or modify 
the agents to use localhost.

doug


>  
>> 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.
> 
> I'm in a meeting right now, but I think I will be able to lead a spike to get 
> Glance off of this if the rest of the Glance team is okay with it.
> 
> --  
> Ian Cordasco
> 
> 
> __
> 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] [all] Maintaining httplib2 python library

[Brian Haley]

On 03/17/2016 06:04 PM, Doug Wiegley wrote:

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.


The Neutron team should talk to Cory Benfield (CC'd) and myself more about this 
if they run into problems. requests and urllib3 are a little limited with 
respect to proxies due to limitations in httplib itself.

Both of us might be able to dedicate time during the day to fix this if 
Neutron/OpenStack have specific requirements that requests is not currently 
capable of supporting.


Looks like neutron is using it to do HTTP requests via unix domain sockets. 
Unless I’m missing something, requests doesn’t support that directly. There are 
a couple of other libs that do, or we could monkey patch the socket. Or modify 
the agents to use localhost.


We have to use Unix domain sockets in the metadata proxy because it's running in 
a namespace, so can't use localhost to talk to the agent.  But we could use some 
other library of course.


-Brian

__
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] [all] Maintaining httplib2 python library

[Gorka Eguileor]

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 <dava...@gmail.com>
> > > Reply: OpenStack Development Mailing List (not for usage questions) 
> > > <openstack-dev@lists.openstack.org>
> > > Date: March 14, 2016 at 09:18:50
> > > To: OpenStack Development Mailing List (not for usage questions) 
> > > <openstack-dev@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[1]. 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 [1] 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 [2] 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 [3].

Cheers,
Gorka.


[1]: https://github.com/google/google-api-python-client/blob/master/setup.py#L66
[2]: https://github.com/Akrog/gcs-client
[3]: 
https://github.com/Akrog/cinder/blob/akrog/gcs_backup/cinder/backup/drivers/gcs.py


> 
> > 
> > +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
> > 
> > _

Re: [openstack-dev] [all] Maintaining httplib2 python library

[Sean McGinnis]

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 <dava...@gmail.com>
> > Reply: OpenStack Development Mailing List (not for usage questions) 
> > <openstack-dev@lists.openstack.org>
> > Date: March 14, 2016 at 09:18:50
> > To: OpenStack Development Mailing List (not for usage questions) 
> > <openstack-dev@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[1]. 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.

> 
> +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-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] [all] Maintaining httplib2 python library

[Jim Rollenhagen]

On Mon, Mar 14, 2016 at 09:24:00AM -0500, Ian Cordasco wrote:
>  
> 
> -Original Message-
> From: Davanum Srinivas <dava...@gmail.com>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: March 14, 2016 at 09:18:50
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@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[1]. 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?"

+1. We just removed the last bits of it from ironicclient.
https://review.openstack.org/#/c/292498

// jim

__
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] [all] Maintaining httplib2 python library

[Monty Taylor]

On 03/14/2016 09:51 AM, Ian Cordasco wrote:

-Original Message-
From: Sean Dague <s...@dague.net>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: March 14, 2016 at 09:41:02
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Maintaining httplib2 python library


On 03/14/2016 10:24 AM, Ian Cordasco wrote:



-Original Message-
From: Davanum Srinivas
Reply: OpenStack Development Mailing List (not for usage questions)
Date: March 14, 2016 at 09:18:50
To: OpenStack Development Mailing List (not for usage questions)
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[1]. 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?"

+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.


The Neutron team should talk to Cory Benfield (CC'd) and myself more about this 
if they run into problems. requests and urllib3 are a little limited with 
respect to proxies due to limitations in httplib itself.

Both of us might be able to dedicate time during the day to fix this if 
Neutron/OpenStack have specific requirements that requests is not currently 
capable of supporting.


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.


I'm in a meeting right now, but I think I will be able to lead a spike to get 
Glance off of this if the rest of the Glance team is okay with it.


I think a spike to get glance off it and then getting everything else to 
requests is the way to go.



__
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] [all] Maintaining httplib2 python library

[Ian Cordasco]

-Original Message-
From: Chris Dent <cdent...@anticdent.org>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: March 14, 2016 at 10:23:04
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Maintaining httplib2 python library

> On Mon, 14 Mar 2016, Ian Cordasco wrote:
>  
> > To be transparent, I've also reached out to Joe to help. My main
> > motivation, though, is to bring it to the point where the
> > recommendation is to use something that is not httplib2 eventually.
> > Not every library needs to live on forever.
>  
> Makes sense. My preference would be to merge the existing pull request
> that are sane, do a release, create a single directory and get rid of
> the weird directory each for 2/3, do another release, and then stick it
> into hard core maintenance mode with the recommendation you mention.
>  
> This would allow it to be a healthy thing for the reluctant to move
> and leave it in a good steady state.
>  
> Maybe that's overkill though. Maybe it is just better to let it fade
> out.

So I've done the "merge a 2/3 split codebase into one" a few times before. It's 
not a trivial amount of work. Doing that kind of work will not lend itself to 
the project maintainers saying "We think this project should be put to rest." 
because the maintainers will have just put in a non-trivial amount of work.

I haven't looked through the open pull requests but there were upwards of 10, 
some of which I would be willing to bet are already conflicting with master and 
others that will conflict with each other. The owners of those PRs probably 
won't care to update them so it will fall to the maintainers to fix those if 
they want to merge them.

Finally there are over 100 open issues. Some of which can be solved for people 
by moving to requests or urllib3 (that I noticed on the first page, e.g., CIDR 
notation in proxy environment variables). The project has been unmaintained 
long enough and should just be put to a tidy rest.

I think the best course forward for a project like httplib2 would be to put it 
into security fix mode only (for some period of time) and urge people to 
migrate as soon as they can before that.

> >> [1] If gabbi were to switch it wouldn't be to requests but probably
> >> urllib3 because the reason httplib2 was chosen is because it does
> >> very little for you and makes few guesses. Requests on the other
> >> hand... However there are no immediate plans to make any changes.
> >
> > As a urllib3 maintainer (and requests maintainer) we should chat about
> > what gabbi needs. I'd be happy to contribute reviews for switching to
> > urllib3.
>  
> I've just had a poke around at urllib3 and it looks like very
> little would be required to make it work with gabbi:
>  
> * adapt the requests intercept in wsgi-intercept to work with
> urllib3 (it's actually intercepting urllib3 anyway, but the
> vendored one)
> * use that intercept in gabbi where needed
> * replace the gabbi.http.client, the interface is much the same
>  
> Small enough that I wouldn't except any speedbumps.
>  
> However, there's no compelling reason to do so (yet) in the sense of
> "it ain't broke".
>  
> Or are you saying that you think it is?

I don't think gabbi or httplib2 is broken. That's not what I'm saying. I think 
every project deserves to be able to die. I think communities think of the 
death of a project as some great tragedy. New and better projects will sprout 
up. Look at what happened with PIL and Pillow. Pillow is a better maintained 
and far more viable replacement for PIL. I bet PIL still has an impressive 
amount of downloads to this day regardless of how easy a transition to Pillow 
should be.

--  
Ian Cordasco


__
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] [all] Maintaining httplib2 python library

[Chris Dent]

On Mon, 14 Mar 2016, Ian Cordasco wrote:


To be transparent, I've also reached out to Joe to help. My main
motivation, though, is to bring it to the point where the
recommendation is to use something that is not httplib2 eventually.
Not every library needs to live on forever.


Makes sense. My preference would be to merge the existing pull request
that are sane, do a release, create a single directory and get rid of
the weird directory each for 2/3, do another release, and then stick it
into hard core maintenance mode with the recommendation you mention.

This would allow it to be a healthy thing for the reluctant to move
and leave it in a good steady state.

Maybe that's overkill though. Maybe it is just better to let it fade
out.


[1] If gabbi were to switch it wouldn't be to requests but probably
urllib3 because the reason httplib2 was chosen is because it does
very little for you and makes few guesses. Requests on the other
hand... However there are no immediate plans to make any changes.


As a urllib3 maintainer (and requests maintainer) we should chat about
what gabbi needs. I'd be happy to contribute reviews for switching to
urllib3.


I've just had a poke around at urllib3 and it looks like very
little would be required to make it work with gabbi:

* adapt the requests intercept in wsgi-intercept to work with
  urllib3 (it's actually intercepting urllib3 anyway, but the
  vendored one)
* use that intercept in gabbi where needed
* replace the gabbi.http.client, the interface is much the same

Small enough that I wouldn't except any speedbumps.

However, there's no compelling reason to do so (yet) in the sense of
"it ain't broke".

Or are you saying that you think it is?

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
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] [all] Maintaining httplib2 python library

[Flavio Percoco]

On 14/03/16 10:16 -0400, Davanum Srinivas wrote:

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[1]. Is there anyone willing to step up?

Thanks,
Dims


[1] 
http://codesearch.openstack.org/?q=(from%7Cimport).*httplib2=nope==



For prettytable we decided to use jazzband[0] instead of adopting it in
OpenStack. I believe it would be a good home for httplib2 as well.

[0] https://jazzband.co/

Flavio

--
@flaper87
Flavio Percoco


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] [all] Maintaining httplib2 python library

[Ian Cordasco]

-Original Message-
From: Chris Dent <cdent...@anticdent.org>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: March 14, 2016 at 09:49:27
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Maintaining httplib2 python library

> On Mon, 14 Mar 2016, Sean Dague wrote:
> > On 03/14/2016 10:24 AM, Ian Cordasco wrote:
> >> 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?"
> >
> > +1.
>  
> Despite volunteering to take care of it, I agree that if it isn't
> needed it shouldn't be used. There is a trend towards using requests
> and most of the time it is probably the better choice. I tend to
> prefer httplib2 because the interface is more semantic for _my_
> specific purposes.
>  
> I'm happy to take it on outside the direct auspices of OpenStack.
> The relative difference between how much Joe has been caring for it
> and giving it a tiny bit of attention just to keep it healthy is
> huge in value, tiny in effort.

To be transparent, I've also reached out to Joe to help. My main motivation, 
though, is to bring it to the point where the recommendation is to use 
something that is not httplib2 eventually. Not every library needs to live on 
forever.

> > 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
>  
> wsgi-intercept (I maintain that) can use httplib2, http.lib or
> requests (and if you go back a few versions even more) so those tests
> could be updated to use requests and still use wsgi-intercept if that
> was desired.
>  
> gabbi relies on httplib2[1] so that's the main motivating factor in me
> wanting to make sure httplib2 has a secure feature. Therefore since
> some OpenStack projects test with gabbi, httplib2 will remain a
> transitive test dependency.
>  
> [1] If gabbi were to switch it wouldn't be to requests but probably
> urllib3 because the reason httplib2 was chosen is because it does
> very little for you and makes few guesses. Requests on the other
> hand... However there are no immediate plans to make any changes.

As a urllib3 maintainer (and requests maintainer) we should chat about what 
gabbi needs. I'd be happy to contribute reviews for switching to urllib3.

--  
Ian Cordasco


__
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] [all] Maintaining httplib2 python library

[Ian Cordasco]

-Original Message-
From: Sean Dague <s...@dague.net>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: March 14, 2016 at 09:41:02
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Maintaining httplib2 python library

> On 03/14/2016 10:24 AM, Ian Cordasco wrote:
> >
> >
> > -Original Message-
> > From: Davanum Srinivas  
> > Reply: OpenStack Development Mailing List (not for usage questions)  
> > Date: March 14, 2016 at 09:18:50
> > To: OpenStack Development Mailing List (not for usage questions)  
> > 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[1]. 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?"
>  
> +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.

The Neutron team should talk to Cory Benfield (CC'd) and myself more about this 
if they run into problems. requests and urllib3 are a little limited with 
respect to proxies due to limitations in httplib itself.

Both of us might be able to dedicate time during the day to fix this if 
Neutron/OpenStack have specific requirements that requests is not currently 
capable of supporting.
 
> 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.

I'm in a meeting right now, but I think I will be able to lead a spike to get 
Glance off of this if the rest of the Glance team is okay with it.

--  
Ian Cordasco


__
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] [all] Maintaining httplib2 python library

[Chris Dent]

On Mon, 14 Mar 2016, Sean Dague wrote:

On 03/14/2016 10:24 AM, Ian Cordasco wrote:

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?"


+1.


Despite volunteering to take care of it, I agree that if it isn't
needed it shouldn't be used. There is a trend towards using requests
and most of the time it is probably the better choice. I tend to
prefer httplib2 because the interface is more semantic for _my_
specific purposes.

I'm happy to take it on outside the direct auspices of OpenStack.
The relative difference between how much Joe has been caring for it
and giving it a tiny bit of attention just to keep it healthy is
huge in value, tiny in effort.


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


wsgi-intercept (I maintain that) can use httplib2, http.lib or
requests (and if you go back a few versions even more) so those tests
could be updated to use requests and still use wsgi-intercept if that
was desired.

gabbi relies on httplib2[1] so that's the main motivating factor in me
wanting to make sure httplib2 has a secure feature. Therefore since
some OpenStack projects test with gabbi, httplib2 will remain a
transitive test dependency.

[1] If gabbi were to switch it wouldn't be to requests but probably
urllib3 because the reason httplib2 was chosen is because it does
very little for you and makes few guesses. Requests on the other
hand... However there are no immediate plans to make any changes.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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] [all] Maintaining httplib2 python library

[Sean Dague]

On 03/14/2016 10:24 AM, Ian Cordasco wrote:
>  
> 
> -Original Message-
> From: Davanum Srinivas <dava...@gmail.com>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: March 14, 2016 at 09:18:50
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@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[1]. 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?"

+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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Maintaining httplib2 python library

[gordon chung]

On 14/03/2016 10:28 AM, Davanum Srinivas wrote:
> Ian,
>
> +1 to get rid of that dependency if possible.
>
> Thanks,
> Dims
>

this. i'm opening a bug to remove this from Ceilometer since it's only 
for a test. i wasn't even aware we had httplib2.

cheers,

-- 
gord

__
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] [all] Maintaining httplib2 python library

[Davanum Srinivas]

Thanks Chris.

On Mon, Mar 14, 2016 at 10:21 AM, Chris Dent  wrote:
> On Mon, 14 Mar 2016, Davanum Srinivas wrote:
>
>> 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[1]. Is there anyone willing to step up?
>
>
> I've been thinking about asking Joe about it for a while, so will
> contact him.
>
> --
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> 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

Re: [openstack-dev] [all] Maintaining httplib2 python library

[Davanum Srinivas]

Ian,

+1 to get rid of that dependency if possible.

Thanks,
Dims

On Mon, Mar 14, 2016 at 10:24 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>
>
> -Original Message-
> From: Davanum Srinivas <dava...@gmail.com>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: March 14, 2016 at 09:18:50
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@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[1]. 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?"
>
> --
> Ian Cordasco
>



-- 
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

Re: [openstack-dev] [all] Maintaining httplib2 python library

[Ian Cordasco]

 

-Original Message-
From: Davanum Srinivas <dava...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: March 14, 2016 at 09:18:50
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@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[1]. 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?"

--  
Ian Cordasco


__
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] [all] Maintaining httplib2 python library

[Chris Dent]

On Mon, 14 Mar 2016, Davanum Srinivas wrote:


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[1]. Is there anyone willing to step up?


I've been thinking about asking Joe about it for a while, so will
contact him.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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-dev] [all] Maintaining httplib2 python library

[Davanum Srinivas]

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[1]. Is there anyone willing to step up?

Thanks,
Dims


[1] 
http://codesearch.openstack.org/?q=(from%7Cimport).*httplib2=nope==

-- 
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