From 5abb1743f3ec0f92adb9fbef139ee51c3b599741 Mon Sep 17 00:00:00 2001 From: Jamie Lennox Date: Thu, 10 Dec 2015 14:15:11 +1100 Subject: [PATCH] Remove confusing documentation When copying this documentation over from keystoneclient we much have simply replaced occurences of keystoneclient with keystoneauth. Details how to migrate keystoneclient to using sessions make sense in keystoneclient however the migration doc makes no sense in keystoneauth1 because those parameters don't exist. Change-Id: I70160f42115d7dfe7610699479baf2e9420fe1b3 --- doc/source/using-sessions.rst | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-) diff --git a/doc/source/using-sessions.rst b/doc/source/using-sessions.rst index ff841699..301f2a56 100644 --- a/doc/source/using-sessions.rst +++ b/doc/source/using-sessions.rst @@ -53,7 +53,7 @@ asked for a valid token. If a valid token is available it will be used otherwise the authentication plugin may attempt to contact the authentication service and fetch a new one. -An example from keystoneauth:: +An example from keystoneclient:: >>> from keystoneauth1.identity import v3 >>> from keystoneauth1 import session @@ -74,31 +74,6 @@ As clients adopt this means of operating they will be created in a similar fashion by passing the Session object to the client's constructor. -Migrating keystoneauth1 to use a Session ------------------------------------------ - -By using a session with a keystoneauth1 Client we presume that you have opted -in to new behavior defined by the session. For example authentication is now -on-demand rather than on creation. To allow this change in behavior there are -a number of functions that have changed behavior or are no longer available. - -For example the -:py:meth:`keystoneauth1.httpclient.HTTPClient.authenticate` method used -to be able to always re-authenticate the current client and fetch a new token. -As this is now controlled by the Session and not the client this has changed, -however the function will still exist to provide compatibility with older -clients. - -Likewise certain parameters such as ``user_id`` and ``auth_token`` that used to -be available on the client object post authentication will remain -uninitialized. - -When converting an application to use a session object with keystoneauth1 you -should be aware of the possibility of changes to authentication and -authentication parameters and make sure to test your code thoroughly. It should -have no impact on the typical CRUD interaction with the client. - - Sharing Authentication Plugins ------------------------------