Openstacksdk
Openstacksdk
Release 0.52.1.dev3
OpenStack Foundation
1 Installation 3
1.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 For Users 5
2.1 Getting started with the OpenStack SDK . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Presentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
4 openstacksdk 569
5 openstack 571
7 openstack.config 575
8 Links 577
8.1 General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Index 583
i
ii
OpenStackSDK Documentation, Release 0.52.1.dev3
CONTENTS 1
OpenStackSDK Documentation, Release 0.52.1.dev3
2 CONTENTS
CHAPTER
ONE
INSTALLATION
1.1 Installation
$ mkvirtualenv openstacksdk
$ pip install openstacksdk
3
OpenStackSDK Documentation, Release 0.52.1.dev3
4 Chapter 1. Installation
CHAPTER
TWO
FOR USERS
For a listing of terms used throughout the SDK, including the names of projects and services supported
by it, see the glossary.
2.1.1 Installation
The OpenStack SDK is available on PyPI under the name openstacksdk. To install it, use pip:
To check the installed version you can call the module with
These guides walk you through how to make use of the libraries we provide to work with each OpenStack
service. If youre looking for a cookbook approach, this is where youll want to begin.
Using os-client-config
Environment Variables
openstacksdk honors all of the normal OS_* variables. It does not provide backwards compatibility to
service-specific variables such as NOVA_USERNAME.
If you have OpenStack environment variables set, openstacksdk will produce a cloud config object
named envvars containing your values from the environment. If you dont like the name envvars, thats
ok, you can override it by setting OS_CLOUD_NAME.
Service specific settings, like the nova service type, are set with the default service type as a prefix. For
instance, to set a special service_type for trove set
5
OpenStackSDK Documentation, Release 0.52.1.dev3
export OS_DATABASE_SERVICE_TYPE=rax:database
Config Files
openstacksdk will look for a file called clouds.yaml in the following locations:
• Current Directory
• ~/.config/openstack
• /etc/openstack
The first file found wins.
You can also set the environment variable OS_CLIENT_CONFIG_FILE to an absolute path of a file to
look for and that location will be inserted at the front of the file search list.
The keys are all of the keys youd expect from OS_* - except lower case and without the OS prefix. So,
region name is set with region_name.
Service specific settings, like the nova service type, are set with the default service type as a prefix. For
instance, to set a special service_type for trove (because youre using Rackspace) set:
database_service_type: 'rax:database'
In addition to ~/.config/openstack and /etc/openstack - some platforms have other locations they like to
put things. openstacksdk will also look in an OS specific config dir
• USER_CONFIG_DIR
• SITE_CONFIG_DIR
USER_CONFIG_DIR is different on Linux, OSX and Windows.
• Linux: ~/.config/openstack
• OSX: ~/Library/Application Support/openstack
• Windows: C:\Users\USERNAME\AppData\Local\OpenStack\openstack
SITE_CONFIG_DIR is different on Linux, OSX and Windows.
• Linux: /etc/openstack
• OSX: /Library/Application Support/openstack
• Windows: C:\ProgramData\OpenStack\openstack
An example config file is probably helpful:
clouds:
mtvexx:
profile: https://vexxhost.com
auth:
username: [email protected]
(continues on next page)
You may note a few things. First, since auth_url settings are silly and embarrassingly ugly, known cloud
vendor profile information is included and may be referenced by name or by base URL to the cloud in
question if the cloud serves a vendor profile. One of the benefits of that is that auth_url isnt the only
thing the vendor defaults contain. For instance, since Rackspace lists rax:database as the service type
for trove, openstacksdk knows that so that you dont have to. In case the cloud vendor profile is not
available, you can provide one called clouds-public.yaml, following the same location rules previously
mentioned for the config files.
regions can be a list of regions. When you call get_all_clouds, youll get a cloud config object for each
cloud/region combo.
As seen with dns_service_type, any setting that makes sense to be per-service, like service_type or
endpoint or api_version can be set by prefixing the setting with the default service type. That might
strike you funny when setting service_type and it does me too - but thats just the world we live in.
Auth Settings
Keystone has auth plugins - which means its not possible to know ahead of time which auth settings
are needed. openstacksdk sets the default plugin type to password, which is what things all were before
plugins came about. In order to facilitate validation of values, all of the parameters that exist as a result
of a chosen plugin need to go into the auth dict. For password auth, this includes auth_url, username
and password as well as anything related to domains, projects and trusts.
Splitting Secrets
In some scenarios, such as configuration management controlled environments, it might be easier to have
secrets in one file and non-secrets in another. This is fully supported via an optional file secure.yaml
which follows all the same location rules as clouds.yaml. It can contain anything you put in clouds.yaml
and will take precedence over anything in the clouds.yaml file.
# clouds.yaml
clouds:
internap:
profile: internap
auth:
username: api-55f9a00fb2619
project_name: inap-17037
regions:
- ams01
- nyj01
# secure.yaml
clouds:
internap:
auth:
password: XXXXXXXXXXXXXXXXX
SSL Settings
When the access to a cloud is done via a secure connection, openstacksdk will always verify the SSL
cert by default. This can be disabled by setting verify to False. In case the cert is signed by an unknown
CA, a specific cacert can be provided via cacert. WARNING: verify will always have precedence over
cacert, so when setting a CA cert but disabling verify, the cloud cert will never be validated.
Client certs are also configurable. cert will be the client cert file location. In case the cert key is not
included within the client cert file, its file location needs to be set via key.
# clouds.yaml
clouds:
regular-secure-cloud:
auth:
auth_url: https://signed.cert.domain:5000
...
unknown-ca-with-client-cert-secure-cloud:
auth:
auth_url: https://unknown.ca.but.secure.domain:5000
...
key: /home/myhome/client-cert.key
cert: /home/myhome/client-cert.crt
cacert: /home/myhome/ca.crt
self-signed-insecure-cloud:
auth:
auth_url: https://self.signed.cert.domain:5000
...
verify: False
Note for parity with openstack command-line options the insecure boolean is also recognised (with
the opposite semantics to verify; i.e. True ignores certificate failures). This should be considered depre-
cated for verify.
Cache Settings
Accessing a cloud is often expensive, so its quite common to want to do some client-side caching of those
operations. To facilitate that, openstacksdk understands passing through cache settings to dogpile.cache,
with the following behaviors:
• Listing no config settings means you get a null cache.
• cache.expiration_time and nothing else gets you memory cache.
• Otherwise, cache.class and cache.arguments are passed in
Different cloud behaviors are also differently expensive to deal with. If you want to get really crazy
and tweak stuff, you can specify different expiration times on a per-resource basis by passing values, in
seconds to an expiration mapping keyed on the singular name of the resource. A value of -1 indicates
that the resource should never expire.
openstacksdk does not actually cache anything itself, but it collects and presents the cache information
so that your various applications that are connecting to OpenStack can share a cache should you desire.
cache:
class: dogpile.cache.pylibmc
expiration_time: 3600
arguments:
url:
- 127.0.0.1
expiration:
server: 5
flavor: -1
clouds:
mtvexx:
profile: vexxhost
auth:
username: [email protected]
password: XXXXXXXXX
project_name: [email protected]
region_name: ca-ymq-1
dns_api_version: 1
IPv6
IPv6 is the future, and you should always use it if your cloud supports it and if your local network
supports it. Both of those are easily detectable and all friendly software should do the right thing.
However, sometimes a cloud API may return IPv6 information that is not useful to a production de-
ployment. For example, the API may provide an IPv6 address for a server, but not provide that to the
host instance via metadata (configdrive) or standard IPv6 autoconfiguration methods (i.e. the host either
needs to make a bespoke API call, or otherwise statically configure itself).
For such situations, you can set the force_ipv4, or OS_FORCE_IPV4 boolean environment variable.
For example:
clouds:
mtvexx:
profile: vexxhost
(continues on next page)
The above snippet will tell client programs to prefer the IPv4 address and leave the public_v6 field
of the Server object blank for the fooprovider cloud . You can also set this with a client flag for all
clouds:
client:
force_ipv4: true
Per-region settings
Sometimes you have a cloud provider that has config that is common to the cloud, but also with some
things you might want to express on a per-region basis. For instance, Internap provides a public and
private network specific to the user in each region, and putting the values of those networks into config
can make consuming programs more efficient.
To support this, the region list can actually be a list of dicts, and any setting that can be set at the cloud
level can be overridden for that region.
clouds:
internap:
profile: internap
auth:
password: XXXXXXXXXXXXXXXXX
username: api-55f9a00fb2619
project_name: inap-17037
regions:
- name: ams01
values:
networks:
- name: inap-17037-WAN1654
routes_externally: true
- name: inap-17037-LAN6745
- name: nyj01
values:
networks:
- name: inap-17037-WAN1654
routes_externally: true
- name: inap-17037-LAN6745
Usage
python -m openstack.config.loader
Which will print out whatever if finds for your config. If you want to use it from python, which is much
more likely what you want to do, things like:
Get a named cloud.
import openstack.config
cloud_region = openstack.config.OpenStackConfig().get_one(
'internap', region_name='ams01')
print(cloud_region.name, cloud_region.region, cloud_region.config)
import openstack.config
cloud_regions = openstack.config.OpenStackConfig().get_all()
for cloud_region in cloud_regions:
print(cloud_region.name, cloud_region.region, cloud_region.config)
argparse
If youre using openstack.config from a program that wants to process command line options, there is a
registration function to register the arguments that both openstack.config and keystoneauth know how to
deal with - as well as a consumption argument.
import argparse
import openstack
parser = argparse.ArgumentParser()
cloud = openstack.connect(options=parser)
Vendor Support
OpenStack presents deployers with many options, some of which can expose differences to end users.
os-client-config tries its best to collect information about various things a user would need to know. The
following is a text representation of the vendor related defaults os-client-config knows about.
Default Values
AURO
https://api.auro.io:5000/v2.0
Betacloud
https://api-1.betacloud.de:5000
Catalyst
https://api.cloud.catalyst.net.nz:5000/v2.0
City Cloud
https://%(region_name)s.citycloud.com:5000/v3/
ConoHa
https://identity.%(region_name)s.conoha.io
DreamCompute
https://iad2.dream.io:5000
https://iam.%(region_name)s.otc.t-systems.com/v3
ELASTX
https://ops.elastx.cloud:5000/v3
https://api.entercloudsuite.com/v2.0
Fuga
https://identity.api.fuga.io:5000
Internap
https://identity.api.cloud.iweb.com/v2.0
Limestone Networks
https://auth.cloud.lstn.net:5000/v3
OVH
https://auth.cloud.ovh.net/v3
Rackspace
https://identity.api.rackspacecloud.com/v2.0/
auth:
username: myusername
api_key: myapikey
auth_type: rackspace_apikey
SWITCHengines
https://keystone.cloud.switch.ch:5000/v3
Ultimum
https://console.ultimum-cloud.com:5000/v2.0
UnitedStack
https://identity.api.ustack.com/v3
VEXXHOST
http://auth.vexxhost.net
Zetta
https://identity.api.zetta.io/v3
Network Config
There are several different qualities that networks in OpenStack might have that might not be able to
be automatically inferred from the available metadata. To help users navigate more complex setups,
os-client-config allows configuring a list of network metadata.
clouds:
amazing:
networks:
- name: blue
routes_externally: true
- name: purple
routes_externally: true
default_interface: true
- name: green
routes_externally: false
- name: yellow
routes_externally: false
nat_destination: true
- name: chartreuse
routes_externally: false
routes_ipv6_externally: true
- name: aubergine
routes_ipv4_externally: false
routes_ipv6_externally: true
Every entry must have a name field, which can hold either the name or the id of the network.
routes_externally is a boolean field that labels the network as handling north/south traffic off of the
cloud. In a public cloud this might be thought of as the public network, but in private clouds its possible
it might be an RFC1918 address. In either case, its provides IPs to servers that things not on the cloud
can use. This value defaults to false, which indicates only servers on the same network can talk to it.
routes_ipv4_externally and routes_ipv6_externally are boolean fields to help handle routes_externally
in the case where a network has a split stack with different values for IPv4 and IPv6. Either entry, if not
given, defaults to the value of routes_externally.
default_interface is a boolean field that indicates that the network is the one that programs should use.
It defaults to false. An example of needing to use this value is a cloud with two private networks, and
where a user is running ansible in one of the servers to talk to other servers on the private network.
Because both networks are private, there would otherwise be no way to determine which one should be
used for the traffic. There can only be one default_interface per cloud.
nat_destination is a boolean field that indicates which network floating ips should be attached to. It
defaults to false. Normally this can be inferred by looking for a network that has subnets that have a
gateway_ip. But its possible to have more than one network that satisfies that condition, so the user
might want to tell programs which one to pick. There can be only one nat_destination per cloud.
nat_source is a boolean field that indicates which network floating ips should be requested from. It
defaults to false. Normally this can be inferred by looking for a network that is attached to a router. But
its possible to have more than one network that satisfies that condition, so the user might want to tell
programs which one to pick. There can be only one nat_source per cloud.
API Reference
get_extra_config(key, defaults=None)
Fetch an arbitrary extra chunk of config, laying in defaults.
Parameters
• key (string) name of the config section to fetch
• defaults (dict) (optional) default values to merge under the found con-
fig
register_argparse_arguments(parser, argv, service_keys=None)
Register all of the common argparse options needed.
Given an argparse parser, register the keystoneauth Session arguments, the keystoneauth
Auth Plugin Options and os-cloud. Also, peek in the argv to see if all of the auth plugin
options should be registered or merely the ones already configured.
Parameters
• argparse.ArgumentParser parser to attach argparse options to
• argv the arguments provided to the application
• service_keys (string) Service or list of services this argparse should
be specialized for, if known. The first item in the list will be used as the
default value for service_type (optional)
:raises exceptions.ConfigException if an invalid auth-type is requested
auth_config_hook(config)
Allow examination of config values before loading auth plugin
OpenStackClient will override this to perform additional checks on auth_type.
option_prompt(config, p_opt)
Prompt user for option that requires a value
magic_fixes(config)
Perform the set of magic argument fixups
get_one(cloud=None, validate=True, argparse=None, **kwargs)
Retrieve a single CloudRegion and merge additional options
Parameters
• cloud (string) The name of the configuration to load from clouds.yaml
• validate (boolean) Validate the config. Setting this to False causes no
auth plugin to be created. Its really only useful for testing.
• argparse (Namespace) An argparse Namespace object; allows direct
passing in of argparse options to be added to the cloud config. Values of
None and will be removed.
• region_name Name of the region of the cloud.
• kwargs Additional configuration options
Returns openstack.config.cloud_region.CloudRegion
Raises keystoneauth1.exceptions.MissingRequiredOptions on missing required
auth parameters
get_one_cloud(cloud=None, validate=True, argparse=None, **kwargs)
Retrieve a single CloudRegion and merge additional options
Parameters
• cloud (string) The name of the configuration to load from clouds.yaml
• validate (boolean) Validate the config. Setting this to False causes no
auth plugin to be created. Its really only useful for testing.
• argparse (Namespace) An argparse Namespace object; allows direct
passing in of argparse options to be added to the cloud config. Values of
None and will be removed.
• region_name Name of the region of the cloud.
• kwargs Additional configuration options
Returns openstack.config.cloud_region.CloudRegion
Raises keystoneauth1.exceptions.MissingRequiredOptions on missing required
auth parameters
get_one_cloud_osc(cloud=None, validate=True, argparse=None, **kwargs)
Retrieve a single CloudRegion and merge additional options
Parameters
• cloud (string) The name of the configuration to load from clouds.yaml
• validate (boolean) Validate the config. Setting this to False causes no
auth plugin to be created. Its really only useful for testing.
• argparse (Namespace) An argparse Namespace object; allows direct
passing in of argparse options to be added to the cloud config. Values of
None and will be removed.
• region_name Name of the region of the cloud.
• kwargs Additional configuration options
Raises keystoneauth1.exceptions.MissingRequiredOptions on missing required
auth parameters
'block_storage_endpoint_override': 'http://...'
'interface': 'public'
property full_name
Return a string that can be used as an identifier.
Always returns a valid string. It will have name and region_name or just one of the two if
only one is set, or else unknown.
set_session_constructor(session_constructor)
Sets the Session constructor.
get_requests_verify_args()
Return the verify and ce