Redirection handling.

Cool ... just needs a unit test and the check for 305 should be explicit, not implied when not 200/204

Also, only handles a single redirect ... you may want to consider the recursive approach I took here:

https://github.com/SandyWalsh/python-novaclient/blob/master/novaclient/client.py

If I remember correctly, nova redirects us directly to keystone. We can't rely on that? I'm not web-world guru, and maybe my assumptions look naive.

While users should be redirected to keystone, most users will start with keystone as their endpoint.

Authentication to keystone is the way you get the endpoints for the user.

Jesse, where do I tell Keystone what the Nova endpoint is for the management_url?

And does it makes sense for Keystone to know about that, since it could be used for may different services? And not having the management_url would bust the way RS Auth works fundamentally, no?

> Jesse, where do I tell Keystone what the Nova endpoint is for the management_url?

Here are examples of setting various endpoints in the service catalog: https://github.com/openstack/keystone/blob/master/bin/sampledata.sh#L47

> And does it makes sense for Keystone to know about that, since it could be used for may different services? And not having the management_url would bust the way RS Auth works fundamentally, no?

I might be missing something (we can bring Ziad over to verify) but I think that is the way RS Auth works:

* Client hits auth endpoint, getting a token and either headers for management urls OR a service catalog (auth 1.x vs 2.0)
* client then hits the management url from header or service catalog

While you might know that the compute endpoint is http://example.com/v1.1/servers - there is no contract in the api that it won't change. The contract is that you re-authenticate to the auth service to get a new token / endpoint...

Does this cause a blowup of the size of the service catalog since it is number of services * number of regions ... YES - but that is what rax idm / public cloud does ... and we need to do it for compatibility :-/

Hmm, i looked in httplib2 code, it can handle all redirects except 305 (surprise!). Maybe it will be more clear to handle all redirects in request() code with small workaround with 305?

Perhaps we can tidy it up a little ... maybe something like: http://paste.openstack.org/show/2131/ (untested)

And would it make sense to share the resp.status handling code in the v1/v2_auth() sections?

and maybe an explicit 'return None' in the success cases?

I tried that, but both versions look very tricky compared to old code. https://github.com/chemikadze/python-novaclient/blob/tricky-retry/novaclient/client.py#L133

Tested on my local installation, log: http://paste.openstack.org/show/2138/

Generally this branch has been working well for me. I see your point about it being equally confusing. I'll merge once we get that little fix and we can re-eval later. Nice work!

Oh, we need a test on this too ... sorry :/

I thought about that, but had not yet time to write tests.

There were a couple of of other PR's that went through too that will require a fresh merge from trunk anyway.

Added tests for redirection.

Sandy, I think all necessary had been done. Tests passing, trunk updates merged (replacing my more general WrongResponse with AuthFailure).

Nice work ... thanks again!