This change is required to return 'request_id' from client
to log request_id mappings of cross-project requests.
Instantiating class 'keystoneclient.v3.client.Client' using
'include_metadata=True' will cause manager response to return
a new 'Response' class instead of just the data. This 'Response'
class is going to have additional metadata properties available
like 'request_ids' and the original data will be available as
property 'data' to it.
This change is backward compatible since user has to set a new
parameter 'include_metadata=True' to client in order to get the
request_id returned.
Co-author: Dinesh Bhor <dinesh.bhor@nttdata.com>
Partially Implements: blueprint return-request-id-to-caller
Change-Id: Ibefaa484158ff08bfcacc1e2802d87fc26fd76a5
Provide support for the domain-specific configuration storage available
via the REST API.
Domain configs are JSON blobs and we have fine grained control on them
via the Identity API. This fine grained control is not defined yet in the
client, though - for now, we can manage everything like Python dictionaries
and use operations like "update" whenever we want to delete a specific group
or option. This approach is similar to what is done in the federation mapping
API to handle mapping rules.
Functional tests are also included, this is useful to check if the new
feature works in an integration environment.
Co-Auhtored-By: Henry Nash <henryn@linux.vnet.ibm.com>
Co-Authored-By: Rodrigo Duarte <rduartes@redhat.com>
Closes-Bug: 1433306
Partially Implements: blueprint domain-config-ext
Change-Id: Ie6795b8633fed38c58b79250c11c9a045b7f95a4
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
Since we'd prefer developers to use the session method when
constructing the Client instance, document it first.
Change-Id: I8998a9962fd541bafae32b3443d7d4767da74257
Rather than just mention the concepts, make each reference a link to
the concept's representation in the API.
Change-Id: I4dadca0395784eb43e5bbb3cfd65c56c8f56ed38
Since developers want to use the APIs, the docs should be more
enticing and say that it describes how to use the APIs.
Also, called it "V3 Client API" since this reads better than
"Client V3 API" and it matches the order in the module path.
Change-Id: I79dd6f6891bf48b477b35157256a0219426d171c
Added a bit more information to the 'using-api-v3' section, about
using sessions instead of passing in arguments.
This overlaps with what is documented in 'using-sessions' but I
think it's still handy as most folks will likely go here first.
Change-Id: I352bda49e01362d3a5da9a79ceb34748552ef9ec
The references to classes and modules were just the names and
didn't link to the docstrings for the class or module. With this
change, names are now links to the class or module.
Change-Id: I9c7c03e8221ca71c7fddc0682abadc7a78d371db
docs/source/using-api.rst documents how to use the V2 API. This patch
starts the equivalent documentation (using-api-v3.rst) about how to
use Keystone v3 API. Introduction and Authentication sections have
been written.
Change-Id: I5a2d45d80ba712492717a75ac5901f5ca775daa4
Partial-Bug: #1260527
