Using the OpenStack SDK¶
This section of documentation pertains to those who wish to use this SDK in their own application. If you’re looking for documentation on how to contribute to or extend the SDK, refer to the contributor section.
For a listing of terms used throughout the SDK, including the names of projects and services supported by it, see the glossary.
These guides walk you through how to make use of the libraries we provide to work with each OpenStack service. If you’re looking for a cookbook approach, this is where you’ll want to begin.
The SDK provides a number of utilities to help you test your applications.
Service APIs are exposed through a two-layered approach. The classes exposed through our Connection interface are the place to start if you’re an application developer consuming an OpenStack cloud. The Resource interface is the layer upon which the Connection is built, with Connection methods accepting and returning Resource objects.
The Cloud Abstraction layer has a data model.
A Connection instance maintains your cloud config, session and authentication information providing you with a set of higher-level interfaces to work with OpenStack services.
The following service proxies exist on the
Connection. The service proxies are all always
present on the
Connection object, but the
combination of your
CloudRegion and the catalog of the cloud in question
control which services can be used.
The Resource layer is a lower-level interface to communicate with OpenStack services. While the classes exposed by the Connection build a convenience layer on top of this, Resources can be used directly. However, the most common usage of this layer is in receiving an object from a class in the Connection layer, modifying it, and sending it back into the Connection layer, such as to update a resource on the server.
The following services have exposed Resource classes.
The following classes are not commonly used by application developers, but are used to construct applications to talk to OpenStack APIs. Typically these parts are managed through the Connection Interface, but their use can be customized.
Errors and warnings¶
The SDK attempts to provide detailed errors and warnings for things like failed requests, deprecated APIs, and invalid configurations. Application developers are responsible for handling these errors and can opt into warnings to ensure their applications stay up-to-date.