Difference between revisions of "Swift/ideas/swiftclient-keystone-session"
Jjw-sohonet (talk | contribs) (Add first pass background discussion) |
Jjw-sohonet (talk | contribs) (→Swiftclient Keystone Session Support) |
||
Line 3: | Line 3: | ||
Proper use of keystone sessions is something we've been talking about at the summits/hackathons for a while :( | 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 | + | 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 means that our 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 | + | The current idea is that when using Keystone for auth, python-swiftclient should be using sessions only as well as allowing an existing session object to be passed in when using the API. The current python-swiftclient code uses access tokens directly by fetching them from the session in order to avoid changing the existing method signatures. |
In order to use sessions as the Keystone project expects we need to do the following: | 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 | + | * All the client API functions need to be refactored to stop adding auth headers and handling tokens manually if a session is present |
− | * | + | * All the client requests should be handled via the auth session if present |
− | |||
− | So it requires a lot of work and will | + | So it requires a lot of work and will possibly 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. | 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. |
Revision as of 17:00, 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 means that our usage of Keystone/Keystone Sessions does not match the current expectations of the Keystone developers.
The current idea is that when using Keystone for auth, python-swiftclient should be using sessions only as well as allowing an existing session object to be passed in when using the API. The current python-swiftclient code uses access tokens directly by fetching them from the session in order to avoid changing the existing method signatures.
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 and handling tokens manually if a session is present
- All the client requests should be handled via the auth session if present
So it requires a lot of work and will possibly 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.