Re: [openstack-dev] requests-mock

[Clay Gerrard]

On Tue, Oct 11, 2016 at 4:24 PM, Jamie Lennox  wrote:

>
> So I'm not going to comment too much on the quality of the library as i
> obviously think it's good
>

acahcpahch, no worries.

Your insights are invaluable - thanks for taking the time to connect some
dots for me - i'm starting to get up to speed.

-Clay
__
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] requests-mock

[Jamie Lennox]

On 11 October 2016 at 16:23, Clay Gerrard  wrote:

> Greetings!
>
> Anyone have any experience to share positive or negative using
> requests-mock?  I see it's been used to replace another dependency that had
> some problems in many of the OpenStack python client libraries:
>
> Added to global requirements -> https://review.openstack.org/#/c/104067
> Added to novaclient -> https://review.openstack.org/#/c/112179/
> Added to cinderclient -> https://review.openstack.org/#/c/106665/
> Added to keystoneclient -> https://review.openstack.org/#/c/106659/
>
> But I'm not sure how folks other than Jamie are getting on with it?  When
> writing new tests do you tend to instinctively grab for requests-mock - or
> do you mostly not notice it's there?  Any unexpected behaviors ever have
> you checking it out with bzr and reading over the source?  Do you recall
> ever having any bumps or bruises in the gate or in your development
> workflow because of a new release from requests-mock?  No presumed fault on
> Jamie!  It seems like he's doing a Herculean one-man job there; but it can
> be difficult go it alone:
>
> https://bugs.launchpad.net/requests-mock/+bug/1616690
>
> It looks like the gate on this project is configured to run nova &
> keystone client tests; so that may be sufficient to catch any sort of issue
> that might come up in something that depends on it?  Presumably once he
> lands a change - he does the update to global-requirements and then all of
> OpenStack get's it from there?
>
> I ask of course because I really don't understand how this works [1] :D
>
> But anyway - Jamie was kind enough to offer to refactor some tests for us
> - but in the process seems to require to bring in these new dependencies -
> so I'm trying to evaluate if I can recommend requiring this code in order
> to develop on swiftclient [2].
>
> Any feedback is greatly appreciated!
>
> -Clay
>
> 1. As you may know (thanks to some recently publicity) swift & swiftclient
> joined OpenStack in the time of dinosaurs with a general policy of trying
> to keep dependencies to a *minimum* - but then one day the policy changed
> to... *always* add dependencies whenever possible?  j/k I'm not acctually
> sure what the OpenStack policy is on dependency hygiene :D  Anyway, I can't
> say *exactly* where that "general policy" came from originally?  Presumably
> crieht or gholt just had some first hand experience that the dependencies
> you choose to add have a HUGE impact on your project over it's lifetime -
> or read something from Joel on Software - http://www.joelonsoftware.com/
> articles/fog07.html - or traveled into the future and read the
> "go proverbs" and google'd "npm breaks internet, again".  Of course they've
> since moved on from OpenStack but the general idea is still something that
> new contributors to swift & swiftclient get acclimated to and the circle of
> confusion continues https://github.com/openstack/swift/blob/master/
> CONTRIBUTING.rst#swift-design-principles - but hey!  maybe I can educate
> myself about the OpenStack policy/process; add this dependency and maybe
> the next one too; then someday break the cycle!?!?
>
> 2. https://review.openstack.org/#/c/360298
>
>
> __
> 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
>
>
Clay,

So I'm not going to comment too much on the quality of the library as i
obviously think it's good (and AFAIK we've never broken an API).

The only thing I'd like to clarify is that I'm never coming to clients with
the intent of converting tests to use requests-mock to promote the library.
I'm probably the main person behind most of the keystoneauth work and one
of the biggest problems I've had with trying to convert projects to work
with keystoneauth (and keystoneclient before that) is that mocking out the
request.request function, or the whole keystoneclient Client as swiftclient
does has made the unit tests very strictly locked to the current way things
are done. By converting the clients to a request level mock I've been able
to change the way the clients authenticate whilst proving there are no
change in the requests made.

The same is true of swiftclient, though it's a longer and slower process
there as i've discussed with people in the past - and would like to try
again at summit. Patches [1][2] exists to bring some support of
keystoneauth to swiftclient (which would make the hacking i'm currently
trying to do on glance_store much easier), but ideally i would like to go
further because there is existing and proven support for things like
reauthenticating a token on 401 via keystoneauth rather than the current,
somewhat hacky method, that would greatly simplify the interaction between
the openstack services and swift.

Swiftclient is 

Re: [openstack-dev] requests-mock

[Clay Gerrard]

On Tue, Oct 11, 2016 at 10:44 AM, Clay Gerrard 
wrote:

>  I'm not really sure what a fixture is this context?
>

Answered my own question in this case!

http://requests-mock.readthedocs.io/en/latest/fixture.html

It's one of *these* of course:

https://pypi.python.org/pypi/fixtures
__
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] requests-mock

[Clay Gerrard]

On Tue, Oct 11, 2016 at 5:40 AM, Ian Cordasco 
wrote:

> So, as a core developer
> of Requests, I would endorse requests-mock for this category of
> dependency.
>

Excellent; exactly the kind of feedback I was hoping to solicit.  If you're
looking to add this catagory of dependency - requests-mock is best-of-breed.

Although, honestly, I was also hoping to get some input from the
perspective of maintaining a client library specifically to address the
question of if this category of dependency is something that makes sense?

e.g.

Ian, you've worked on glance - so I went looking how glanceclient uses
requests_mock and found another change from Jamie:

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

In this change, it *seems* like instead of glanceclient maintaining some
stubs that are used to set explicit expectations about the external
behavior of the other system - glaceclient has *outsourced* it's
expectations to implicitly couple with whatever keystoneclient provides.
On one hand this seems like it might reduce some maintenance burden.  OTOH,
the burden of maintaining some of the expectations about the behavior of
the external system you depend on seems *related* to maintaining the glance
client?  I'm not sure if this is a great tradeoff?  Maybe?  I'm not sure if
this gets into what you were talking about wrt integration tests?  The
change I'm currently evaluating doesn't import an external fixture I don't
think... I'm not really sure what a fixture is this context?

http://requests-mock.readthedocs.io/en/latest/api/requests_mock.html?highlight=fixture#requests-mock-fixture-module

-Clay
__
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] requests-mock

[Ian Cordasco]

-Original Message-
From: Clay Gerrard <clay.gerr...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: October 11, 2016 at 00:25:10
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] requests-mock

> Greetings!
>
> Anyone have any experience to share positive or negative using
> requests-mock? I see it's been used to replace another dependency that had
> some problems in many of the OpenStack python client libraries:
>
> Added to global requirements -> https://review.openstack.org/#/c/104067
> Added to novaclient -> https://review.openstack.org/#/c/112179/
> Added to cinderclient -> https://review.openstack.org/#/c/106665/
> Added to keystoneclient -> https://review.openstack.org/#/c/106659/
>
> But I'm not sure how folks other than Jamie are getting on with it? When
> writing new tests do you tend to instinctively grab for requests-mock - or
> do you mostly not notice it's there? Any unexpected behaviors ever have
> you checking it out with bzr and reading over the source? Do you recall
> ever having any bumps or bruises in the gate or in your development
> workflow because of a new release from requests-mock? No presumed fault on
> Jamie! It seems like he's doing a Herculean one-man job there; but it can
> be difficult go it alone:
>
> https://bugs.launchpad.net/requests-mock/+bug/1616690
>
> It looks like the gate on this project is configured to run nova & keystone
> client tests; so that may be sufficient to catch any sort of issue that
> might come up in something that depends on it? Presumably once he lands a
> change - he does the update to global-requirements and then all of
> OpenStack get's it from there?
>
> I ask of course because I really don't understand how this works [1] :D
>
> But anyway - Jamie was kind enough to offer to refactor some tests for us -
> but in the process seems to require to bring in these new dependencies - so
> I'm trying to evaluate if I can recommend requiring this code in order to
> develop on swiftclient [2].
>
> Any feedback is greatly appreciated!
>
> -Clay
>
> 1. As you may know (thanks to some recently publicity) swift & swiftclient
> joined OpenStack in the time of dinosaurs with a general policy of trying
> to keep dependencies to a *minimum* - but then one day the policy changed
> to... *always* add dependencies whenever possible? j/k I'm not acctually
> sure what the OpenStack policy is on dependency hygiene :D Anyway, I can't
> say *exactly* where that "general policy" came from originally? Presumably
> crieht or gholt just had some first hand experience that the dependencies
> you choose to add have a HUGE impact on your project over it's lifetime -
> or read something from Joel on Software -
> http://www.joelonsoftware.com/articles/fog07.html - or traveled
> into the future and read the "go proverbs" and google'd "npm breaks
> internet, again". Of course they've since moved on from OpenStack but the
> general idea is still something that new contributors to swift &
> swiftclient get acclimated to and the circle of confusion continues
> https://github.com/openstack/swift/blob/master/CONTRIBUTING.rst#swift-design-principles
> - but hey! maybe I can educate myself about the OpenStack policy/process;
> add this dependency and maybe the next one too; then someday break the
> cycle!?!?
>
> 2. https://review.openstack.org/#/c/360298

Hi Clay!

I have a complex set of opinions about requests-mock. First, let me
start by saying that when people start asking about httpretty versus
responses versus the N other libraries that do similar things versus
requests-mock, I always tell them to use requests-mock. The rest are
hacky and poorly done and (unlike Jamie) do not take critical feedback
regarding their approach to the problem well. requests-mock has only
ever improved since I've become aware of it and the only bugs it has
run into have been due to changes in Requests. So, as a core developer
of Requests, I would endorse requests-mock for this category of
dependency.

Now, my problem with requests-mock stem from the way it encourages you
to write unit tests. (Or at least, the way most people in OpenStack
write "unit" tests with it.) Most of the time, what you'll see is that
someone starts using requests-mock and hand writes their data and
response headers into the mock object. They then do something with a
much higher-level object and assert things like a Resource object has
the correct attributes. So they're not testing that the library makes
the request the way they expect it to. They're asserting that the
request is made that way AND everything else does it's job o

Re: [openstack-dev] requests-mock

[Davanum Srinivas]

Clay,

Apologies for the top post. Here's the current recommendation on
dependencies - Answering your question on "I'm not acctually sure what
the OpenStack policy is on dependency hygiene :D  Anyway,":
https://github.com/openstack/requirements#global-requirements-for-openstack-projects

There is a requirements team, you can reach them on the
#openstack-requirements channel:
https://wiki.openstack.org/wiki/Requirements

-- Dims

On Tue, Oct 11, 2016 at 1:23 AM, Clay Gerrard  wrote:
> Greetings!
>
> Anyone have any experience to share positive or negative using
> requests-mock?  I see it's been used to replace another dependency that had
> some problems in many of the OpenStack python client libraries:
>
> Added to global requirements -> https://review.openstack.org/#/c/104067
> Added to novaclient -> https://review.openstack.org/#/c/112179/
> Added to cinderclient -> https://review.openstack.org/#/c/106665/
> Added to keystoneclient -> https://review.openstack.org/#/c/106659/
>
> But I'm not sure how folks other than Jamie are getting on with it?  When
> writing new tests do you tend to instinctively grab for requests-mock - or
> do you mostly not notice it's there?  Any unexpected behaviors ever have you
> checking it out with bzr and reading over the source?  Do you recall ever
> having any bumps or bruises in the gate or in your development workflow
> because of a new release from requests-mock?  No presumed fault on Jamie!
> It seems like he's doing a Herculean one-man job there; but it can be
> difficult go it alone:
>
> https://bugs.launchpad.net/requests-mock/+bug/1616690
>
> It looks like the gate on this project is configured to run nova & keystone
> client tests; so that may be sufficient to catch any sort of issue that
> might come up in something that depends on it?  Presumably once he lands a
> change - he does the update to global-requirements and then all of OpenStack
> get's it from there?
>
> I ask of course because I really don't understand how this works [1] :D
>
> But anyway - Jamie was kind enough to offer to refactor some tests for us -
> but in the process seems to require to bring in these new dependencies - so
> I'm trying to evaluate if I can recommend requiring this code in order to
> develop on swiftclient [2].
>
> Any feedback is greatly appreciated!
>
> -Clay
>
> 1. As you may know (thanks to some recently publicity) swift & swiftclient
> joined OpenStack in the time of dinosaurs with a general policy of trying to
> keep dependencies to a *minimum* - but then one day the policy changed to...
> *always* add dependencies whenever possible?  j/k I'm not acctually sure
> what the OpenStack policy is on dependency hygiene :D  Anyway, I can't say
> *exactly* where that "general policy" came from originally?  Presumably
> crieht or gholt just had some first hand experience that the dependencies
> you choose to add have a HUGE impact on your project over it's lifetime - or
> read something from Joel on Software -
> http://www.joelonsoftware.com/articles/fog07.html - or traveled into
> the future and read the "go proverbs" and google'd "npm breaks internet,
> again".  Of course they've since moved on from OpenStack but the general
> idea is still something that new contributors to swift & swiftclient get
> acclimated to and the circle of confusion continues
> https://github.com/openstack/swift/blob/master/CONTRIBUTING.rst#swift-design-principles
> - but hey!  maybe I can educate myself about the OpenStack policy/process;
> add this dependency and maybe the next one too; then someday break the
> cycle!?!?
>
> 2. https://review.openstack.org/#/c/360298
>
>
> __
> 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

[openstack-dev] requests-mock

[Clay Gerrard]

Greetings!

Anyone have any experience to share positive or negative using
requests-mock?  I see it's been used to replace another dependency that had
some problems in many of the OpenStack python client libraries:

Added to global requirements -> https://review.openstack.org/#/c/104067
Added to novaclient -> https://review.openstack.org/#/c/112179/
Added to cinderclient -> https://review.openstack.org/#/c/106665/
Added to keystoneclient -> https://review.openstack.org/#/c/106659/

But I'm not sure how folks other than Jamie are getting on with it?  When
writing new tests do you tend to instinctively grab for requests-mock - or
do you mostly not notice it's there?  Any unexpected behaviors ever have
you checking it out with bzr and reading over the source?  Do you recall
ever having any bumps or bruises in the gate or in your development
workflow because of a new release from requests-mock?  No presumed fault on
Jamie!  It seems like he's doing a Herculean one-man job there; but it can
be difficult go it alone:

https://bugs.launchpad.net/requests-mock/+bug/1616690

It looks like the gate on this project is configured to run nova & keystone
client tests; so that may be sufficient to catch any sort of issue that
might come up in something that depends on it?  Presumably once he lands a
change - he does the update to global-requirements and then all of
OpenStack get's it from there?

I ask of course because I really don't understand how this works [1] :D

But anyway - Jamie was kind enough to offer to refactor some tests for us -
but in the process seems to require to bring in these new dependencies - so
I'm trying to evaluate if I can recommend requiring this code in order to
develop on swiftclient [2].

Any feedback is greatly appreciated!

-Clay

1. As you may know (thanks to some recently publicity) swift & swiftclient
joined OpenStack in the time of dinosaurs with a general policy of trying
to keep dependencies to a *minimum* - but then one day the policy changed
to... *always* add dependencies whenever possible?  j/k I'm not acctually
sure what the OpenStack policy is on dependency hygiene :D  Anyway, I can't
say *exactly* where that "general policy" came from originally?  Presumably
crieht or gholt just had some first hand experience that the dependencies
you choose to add have a HUGE impact on your project over it's lifetime -
or read something from Joel on Software -
http://www.joelonsoftware.com/articles/fog07.html - or traveled
into the future and read the "go proverbs" and google'd "npm breaks
internet, again".  Of course they've since moved on from OpenStack but the
general idea is still something that new contributors to swift &
swiftclient get acclimated to and the circle of confusion continues
https://github.com/openstack/swift/blob/master/CONTRIBUTING.rst#swift-design-principles
- but hey!  maybe I can educate myself about the OpenStack policy/process;
add this dependency and maybe the next one too; then someday break the
cycle!?!?

2. https://review.openstack.org/#/c/360298
__
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