summaryrefslogtreecommitdiff
path: root/doc/source/using-sessions.rst
diff options
context:
space:
mode:
authorBrant Knudson <bknudson@us.ibm.com>2016-02-28 10:44:44 -0600
committerBrant Knudson <bknudson@us.ibm.com>2016-02-28 17:17:33 +0000
commiteb70a26a60dd81e3639b3fadd8251f8cfc337539 (patch)
tree77b965218c058111098a4a4874f95668ebb94a94 /doc/source/using-sessions.rst
parent7d57eceb19aaaca8de84a8701552715fc8153872 (diff)
downloadpython-keystoneclient-eb70a26a60dd81e3639b3fadd8251f8cfc337539.tar.gz
Update developer docs for keystoneauth session
The developer docs should tell developers to use keystoneauth1 sessions rather than keystoneclient sessions or passing arguments to the Client constructors. keystoneclient sessions and constructing Clients using non-sessions is deprecated. Change-Id: Ica19b8d6fb2f5d1a9d0d22d4fe08abb266fd6a86
Diffstat (limited to 'doc/source/using-sessions.rst')
-rw-r--r--doc/source/using-sessions.rst17
1 files changed, 9 insertions, 8 deletions
diff --git a/doc/source/using-sessions.rst b/doc/source/using-sessions.rst
index cd8fbb4..a5a5a58 100644
--- a/doc/source/using-sessions.rst
+++ b/doc/source/using-sessions.rst
@@ -5,7 +5,7 @@ Using Sessions
Introduction
============
-The :py:class:`keystoneclient.session.Session` class was introduced into
+The :py:class:`keystoneauth1.session.Session` class was introduced into
keystoneclient as an attempt to bring a unified interface to the various
OpenStack clients that share common authentication and request parameters
between a variety of services.
@@ -55,8 +55,8 @@ service and fetch a new one.
An example from keystoneclient::
- >>> from keystoneclient.auth.identity import v3
- >>> from keystoneclient import session
+ >>> from keystoneauth1.identity import v3
+ >>> from keystoneauth1 import session
>>> from keystoneclient.v3 import client
>>> auth = v3.Password(auth_url='https://my.keystone.com:5000/v3',
@@ -189,11 +189,12 @@ While authentication plugins will endeavour to maintain a consistent set of
arguments for an ``endpoint_filter`` the concept of an authentication plugin is
purposefully generic and a specific mechanism may not know how to interpret
certain arguments and ignore them. For example the
-:py:class:`keystoneclient.auth.token_endpoint.Token` plugin (which is used when
-you want to always use a specific endpoint and token combination) will always
-return the same endpoint regardless of the parameters to ``endpoint_filter`` or
-a custom OpenStack authentication mechanism may not have the concept of
-multiple ``interface`` options and choose to ignore that parameter.
+:py:class:`keystoneauth1.identity.generic.token.Token` plugin (which is used
+when you want to always use a specific endpoint and token combination) will
+always return the same endpoint regardless of the parameters to
+``endpoint_filter`` or a custom OpenStack authentication mechanism may not have
+the concept of multiple ``interface`` options and choose to ignore that
+parameter.
There is some expectation on the user that they understand the limitations of
the authentication system they are using.