RETIRED, further work has moved to Debian project infrastructure
d5149c9df0
While investigating an issue with us improperly determining the Identity endpoints between v2 and v3, it was mentioned several times that we should really be getting endpoints directly from the services, not from the service catalog. Part of this was a forward looking mention, as eventually services will be unversioned in the catalog. It's also a current issue as Identity themselves do not provide a v3 endpoint in the service catalog--only v2. This change introduces an implementation of Session.get_endpoint that uses the service catalog to get started, taking only the root of a service's endpoint, and then making a GET call to that root to find the versions and endpoints it is configured for. Once we've received the supported versions, we use somewhat of a fuzzy match to determine the exact endpoint. When a profile specifies v2 for a service, we'll look for the latest v2 offered, which could be v2.2 while it also offers v2.0 and v2.1. When a user asks specifically for v2.1, they will get exactly that. The one place we don't fuzzily match is across major versions, so if a user asks for a v3 but the service is only providing v2 at the moment, an exception will be raised. This adds an additional field to the ServiceFilter, requires_project_id, because there are some services that require a project id in their URI and some don't. We were apparently getting that straight from the service catalog before, but now we need services to tell us when they need it. Now for the special cases: * object_store doesn't help us with any of this. It still comes straight out of the service catalog. * some services only provide version fragments, not full URIs, so we need to reconstruct them to prepend the root. * identity nests the versions within another dictionary of "values" For any given combination of service_type and interface, a request to determine the versions is only made once. The endpoints are cached in a dictionary that is per-Connection instance. Change-Id: I0958ce5d7477da106890dc7770ac013d5b9098f6 |
||
|---|---|---|
| doc | ||
| examples | ||
| openstack | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .testr.conf | ||
| babel.cfg | ||
| CONTRIBUTING.rst | ||
| create_yaml.sh | ||
| docs-requirements.txt | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| post_test_hook.sh | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
OpenStack Python SDK
The python-openstacksdk is a collection of libraries for
building applications to work with OpenStack clouds. The project aims to
provide a consistent and complete set of interactions with OpenStack's
many services, along with complete documentation, examples, and
tools.
This SDK is under active development, and in the interests of providing a high-quality interface, the APIs provided in this release may differ from those provided in future release.
Usage
The following example simply connects to an OpenStack cloud and lists the containers in the Object Store service.:
from openstack import connection
conn = connection.Connection(auth_url="http://openstack:5000/v3",
project_name="big_project",
username="SDK_user",
password="Super5ecretPassw0rd")
for container in conn.object_store.containers():
print(container.name)Documentation
Documentation is available at http://developer.openstack.org/sdks/python/openstacksdk/
License
Apache 2.0