OpenStack Compute Driver Documentation
======================================

`OpenStack`_ is an open-source project which allows you to build and run your
own public or private cloud.

.. figure:: /_static/images/provider_logos/openstack.png
    :align: center
    :width: 200
    :target: http://www.openstack.org/

Among many other private clouds, it also powers Rackspace's Public Cloud.

.. _connecting-to-openstack-installation:

Selecting the Nova API version
------------------------------

Along with your connection criteria, you can specify the Nova version with `api_version`,
currently supported versions of Nova are:

- 1.0
- 1.1
- 2.0
- 2.1 (v12)
- 2.2 (v13)

.. code-block:: python

  from libcloud.compute.providers import get_driver
  from libcloud.compute.types import Provider

  Openstack = get_driver(Provider.OPENSTACK)

  con = Openstack(
      'admin', 'password',
      ex_force_base_url='http://23.12.198.36:8774/v2.1',
      api_version='2.0',
      ex_tenant_name='demo')


Connecting to the OpenStack installation
----------------------------------------

OpenStack driver constructor takes different arguments with which you describe
your OpenStack installation. Those arguments describe things such as the
authentication service API URL, authentication service API version and so on.

Keep in mind that the majority of those arguments are optional and in the most
common scenario with a default installation, you will only need to provide
``ex_force_auth_url`` argument.

Available arguments:

* ``ex_force_auth_url`` - Authentication service (Keystone) API URL. It can
  either be a full URL with a path (e.g.
  ``https://192.168.1.101:5000/v2.0/tokens/``) or a base URL without a path
  (e.g. ``https://192.168.1.1``). If no path is provided, default path for the
  provided auth version is appended to the base URL.
* ``ex_force_auth_version`` - API version of the authentication service. This
  argument determines how authentication is performed. Valid and supported
  versions are:

  * ``1.0`` - authenticate against the keystone using the provided username
    and API key (old and deprecated version which was used by Rackspace in
    the past)
  * ``1.1`` - authenticate against the keystone using the provided username
    and API key (old and deprecated version which was used by Rackspace in
    the past)
  * ``2.0`` or ``2.0_apikey`` - authenticate against keystone with a username
    and API key
  * ``2.0_password`` - authenticate against keystone with a username and
    password
  * ``2.0_voms`` - 2.0 VOMS key
  * ``3.x_password`` - 3.x keystone password
  * ``3.x_appcred`` - 3.x keystone with application credential
  * ``3.x_oidc_access_token`` - OIDC access token


  Unless you are working with a very old version of OpenStack you will either
  want to use ``2.0_*`` or ``3.x_*``.
* ``ex_tenant_name`` - tenant / project name
* ``ex_force_auth_token`` - token which is used for authentication. If this
  argument is provided, normal authentication flow is skipped and the OpenStack
  API endpoint is directly hit with the provided token.
  Normal authentication flow involves hitting the auth service (Keystone) with
  the provided username and either password or API key and requesting an
  authentication token.
* ``ex_force_service_type``
* ``ex_force_service_name``
* ``ex_force_service_region``
* ``ex_force_base_url`` - Base URL to the OpenStack nova API endpoint. By default,
  driver obtains API endpoint URL from the server catalog, but if this argument
  is provided, this step is skipped and the provided value is used directly.
* ``ex_force_network_url`` - Base URL to the OpenStack neutron API endpoint. By default,
  driver obtains API endpoint URL from the server catalog, but if this argument
  is provided, this step is skipped and the provided value is used directly. Only valid
  in case of api_version >= 2.0.
* ``ex_force_image_url`` - Base URL to the OpenStack glance API endpoint. By default,
  driver obtains API endpoint URL from the server catalog, but if this argument
  is provided, this step is skipped and the provided value is used directly. Only valid
  in case of api_version >= 2.0.
* ``ex_force_volume_url`` - Base URL to the OpenStack cinder API endpoint. By default,
  driver obtains API endpoint URL from the server catalog, but if this argument
  is provided, this step is skipped and the provided value is used directly. Only valid
  in case of api_version >= 2.0.
* ``ex_force_microversion`` - Microversion of the API to interact with OpenStack.
  Only valid in case of api_version >= 2.0.

Some examples which show how to use this arguments can be found in the section
below.

Examples
--------

1. Most common use case - specifying only authentication service endpoint URL and API version
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. literalinclude:: /examples/compute/openstack/simple_auth.py
   :language: python

2. Specifying which entry to select in the service catalog using service_type service_name and service_region arguments
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. literalinclude:: /examples/compute/openstack/custom_service_catalog_selection_args.py
   :language: python

3. Skipping the endpoint selection using service catalog by providing ``ex_force_base_url`` argument
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Keep in mind that the base url must also contain tenant id as the last
component of the URL (``12345`` in the example below).

.. literalinclude:: /examples/compute/openstack/force_base_url.py
   :language: python

4. Skipping normal authentication flow and hitting the API endpoint directly using the ``ex_force_auth_token`` argument
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is an advanced use cases which assumes you manage authentication and token
retrieval yourself.

If you use this argument, the driver won't hit authentication service and as
such, won't be aware of the token expiration time.

This means auth token will be considered valid for the whole life time of the
driver instance and you will need to manually re-instantiate a driver with a new
token before the currently used one is about to expire.

.. literalinclude:: /examples/compute/openstack/force_auth_token.py
   :language: python

5. Connecting and specifying a tenant
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This example shows how to connect to OpenStack installation which requires you
to specify a tenant (``ex_tenant_name`` argument).

.. literalinclude:: /examples/compute/openstack/tenant_name.py
   :language: python

6. HP Cloud (www.hpcloud.com)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Connecting to HP Cloud US West and US East (OpenStack Havana).

.. literalinclude:: /examples/compute/openstack/hpcloud.py
   :language: python

7. Using Cloud-Init with OpenStack
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This example shows how to use cloud-init using the ``ex_config_drive`` and
``ex_userdata`` arguments to ``create_node``. This example just installs
nginx and starts it. More `Cloud-Init examples`_.

Note: You will need to use a cloud-init enabled image. Most Openstack based
public cloud providers support it.

.. literalinclude:: /examples/compute/openstack/cloud_init.py
   :language: python
.. _`Cloud-Init examples`: http://cloudinit.readthedocs.org/en/latest/topics/examples.html

8. Authentication token cache
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Since version ???, authentication tokens can be stored in an external cache.
This enables multiple processes to reuse the tokens, reducing the number of
token allocations in the OpenStack authentication service.

.. literalinclude:: /examples/compute/openstack/auth_cache.py
   :language: python

If the cache implementation stores tokens somewhere outside the process - for
instance, to disk or a remote system - running this program twice will
allocate a token from OpenStack, store it in the cache, then reuse that token
on the second run.

Non-standard functionality and extension methods
------------------------------------------------

OpenStack driver exposes a bunch of non-standard functionality through
extension methods and arguments.

This functionality includes:

* server image management
* network management
* floating IP management
* key-pair management

For information on how to use this functionality please see the method
docstrings below.

Other Information
-----------------

Authentication token re-use
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Since version 0.13.0, the driver caches auth token in memory and re-uses it
between different requests.

This means that driver will only hit authentication service and obtain auth
token on the first request or if the auth token is about to expire.

As noted in the example 4 above, this doesn't hold true if you use
``ex_force_auth_token`` argument.

Tokens can also be stored in an external cache for shared use among multiple
processes; see example 8 above.

Troubleshooting
---------------

I get ``Could not find specified endpoint`` error
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This error indicates that the driver couldn't find a specified API endpoint
in the service catalog returned by the authentication service.

There are many different things which could cause this error:

1. Service catalog is empty
2. You have not specified a value for one of the following arguments
   ``ex_force_service_type``, ``ex_force_service_name``, ``ex_force_service_region`` and the
   driver is using the default values which don't match your installation.
3. You have specified invalid value for one or all of the following arguments:
   ``ex_force_service_type``, ``ex_force_service_name``, ``ex_force_service_region``

The best way to troubleshoot this issue is to use ``LIBCLOUD_DEBUG``
functionality which is documented in the debugging section. This
functionality allows you to introspect the response from the authentication
service and you can make sure that ``ex_force_service_type``, ``ex_force_service_name``,
``ex_force_service_region`` arguments match values returned in the service catalog.

If the service catalog is empty, you have two options:

1. Populate the service catalog and makes sure the ``ex_force_service_type``,
   ``ex_force_service_name`` and ``ex_force_service_region`` arguments match the values
   defined in the service catalog.
2. Provide the API endpoint url using ``ex_force_base_url`` argument and skip
   the "endpoint selection using the service catalog" step all together

I get ``Resource not found`` error
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This error most likely indicates that you have used an invalid value for the
``ex_force_base_url`` argument.

Keep in mind that this argument should point to the OpenStack API endpoint and
not to the authentication service API endpoint. API service and authentication
service are two different services which listen on different ports.

API Docs
--------

Please note that there are two API versions of the OpenStack Compute API, which
are supported by two different subclasses of the OpenStackNodeDriver. The
default is the 1.1 API. The 1.0 API is supported to be able to connect to
OpenStack instances which do not yet support the version 1.1 API.

Compute 2.0 API version (current)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. autoclass:: libcloud.compute.drivers.openstack.OpenStack_2_NodeDriver
    :members:
    :inherited-members:

Compute 1.1 API version (old installations)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. autoclass:: libcloud.compute.drivers.openstack.OpenStack_1_1_NodeDriver
    :members:
    :inherited-members:

Compute 1.0 API version (older installations)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. autoclass:: libcloud.compute.drivers.openstack.OpenStack_1_0_NodeDriver
    :members:
    :inherited-members:

.. _`OpenStack`: http://www.openstack.org/