Difference between revisions of "Swift/ideas/swiftclient-keystone-session"
Jjw-sohonet (talk | contribs) (Add past patch links) |
Jjw-sohonet (talk | contribs) (Add first pass background discussion) |
||
| Line 1: | Line 1: | ||
= Swiftclient Keystone Session Support = | = Swiftclient Keystone Session Support = | ||
| − | Some work has been done in the past on a very lightweight method to allow the python-swiftclient to make use of Keystone sessions whilst maintaining the existing API. However, more recent updates to Keystone, and the deprecation of version specific sessions mean that we may need to explore supporting Keystone sessions more thoroughly. | + | Proper use of keystone sessions is something we've been talking about at the summits/hackathons for a while :( |
| + | |||
| + | Some work has been done in the past on a very lightweight method to allow the python-swiftclient to make use of Keystone sessions whilst maintaining the existing API. However, more recent updates to Keystone, and the deprecation of version specific sessions mean that we may need to explore supporting Keystone sessions more thoroughly. The big problem is that, in the current python-swiftclient code, the usage of Keystone/Keystone Sessions does not match the current expectations of the Keystone developers. | ||
| + | |||
| + | The idea is that when using Keystone for auth, swiftclient should be using sessions only and allow an existing session to be passed in when using the API. The current code uses access tokens by fetching them from the session directly in order to avoid changing the existing method signatures. Ultimately, when using Keystone, swiftclient shouldn't be even importing keystoneclient at all, all it should need is keystoneauth. | ||
| + | |||
| + | In order to use sessions as the Keystone project expects we need to do the following: | ||
| + | |||
| + | * All the client API functions need to be refactored to stop adding auth headers manually if a session is present | ||
| + | * Pass around parameters such as the certs and the verify as well, since those would be used by the session | ||
| + | * Make sure we can still use v1 auth! | ||
| + | |||
| + | So it requires a lot of work and will probably break the API :S | ||
| + | |||
| + | Another point of discussion from a previous (now abandoned) patch brought up the idea that perhaps we shouldn't be specifying the keystone version at all, but instead making use of keystoneauth's version discovery, but again this comes with it's own subtle changes to behaviour to all the swiftclient layers including the CLI. | ||
== Current Patch and Related Discussion == | == Current Patch and Related Discussion == | ||
| − | Patch "Use keystone session when possible" [https://review.openstack.org/#/c/456205/] has been added by jaosorior as | + | Patch "Use keystone session when possible" [https://review.openstack.org/#/c/456205/] has been added by jaosorior as a starting point and indication of what changes would be required within python-swiftclient to properly support generic Keystone sessions and Keystone version detection. |
== Past Related Patches == | == Past Related Patches == | ||
Revision as of 16:08, 3 May 2017
Swiftclient Keystone Session Support
Proper use of keystone sessions is something we've been talking about at the summits/hackathons for a while :(
Some work has been done in the past on a very lightweight method to allow the python-swiftclient to make use of Keystone sessions whilst maintaining the existing API. However, more recent updates to Keystone, and the deprecation of version specific sessions mean that we may need to explore supporting Keystone sessions more thoroughly. The big problem is that, in the current python-swiftclient code, the usage of Keystone/Keystone Sessions does not match the current expectations of the Keystone developers.
The idea is that when using Keystone for auth, swiftclient should be using sessions only and allow an existing session to be passed in when using the API. The current code uses access tokens by fetching them from the session directly in order to avoid changing the existing method signatures. Ultimately, when using Keystone, swiftclient shouldn't be even importing keystoneclient at all, all it should need is keystoneauth.
In order to use sessions as the Keystone project expects we need to do the following:
- All the client API functions need to be refactored to stop adding auth headers manually if a session is present
- Pass around parameters such as the certs and the verify as well, since those would be used by the session
- Make sure we can still use v1 auth!
So it requires a lot of work and will probably break the API :S
Another point of discussion from a previous (now abandoned) patch brought up the idea that perhaps we shouldn't be specifying the keystone version at all, but instead making use of keystoneauth's version discovery, but again this comes with it's own subtle changes to behaviour to all the swiftclient layers including the CLI.
Current Patch and Related Discussion
Patch "Use keystone session when possible" [1] has been added by jaosorior as a starting point and indication of what changes would be required within python-swiftclient to properly support generic Keystone sessions and Keystone version detection.
