Contents

1   Introduction

This document serves as an introduction to the Application Programming Interface (API) of the OpenStack Dashboard based cloud management component Atlas, in the Cloud Execution Environment (CEE).

The API is used for orchestration purposes in CEE.

The document describes the modifications made to the OpenStack Orchestration Newton version.

1.1   API Version

The Atlas orchestration API is based on OpenStack Orchestration API v1.

1.2   Document References

This section lists the official OpenStack API references.

1.2.1   API Design Base Reference

For a detailed description of the API operations and extensions of orchestration, refer to the section "Orchestration API v1" in the OpenStack API Complete Reference.

This is a stored copy of the OpenStack API reference document that was the base for the development of this version of CEE.

All references to this OpenStack API made in this document are based on this specific document version. The document may include API Extensions that are not supported in this version of CEE. For details, see Section 2.2.

Note:  

It is possible that the date on the front page differs from the one above, since the former shows the date on which the document was generated.

1.2.2   API Template Reference

For a detailed description of the Heat template, refer to OpenStack Heat.

This is a stored copy of the OpenStack Heat template reference document that was the base for the development of this version of CEE.

Note:  

It is possible that the date on the front page differs from the one above, since the former shows the date on which the document was generated.

2   Supported Operations

This section contain information about the API operations and API extensions in CEE.

2.1   Basic OpenStack Operations

Atlas orchestration supports all basic Orchestration API operations.

For a detailed description of the API operations and extensions of orchestration, refer to the section "Orchestration API v1" in the OpenStack API Complete Reference.

2.1.1   Limitations

Not applicable.

2.1.2   OpenStack Template Reference

CEE Orchestration supports all Template Reference.

For a detailed description of the Heat template, refer to OpenStack Heat.

2.2   OpenStack Extensions

This section lists the OpenStack API extensions that are used in CEE.

CEE orchestration supports the Identity API v2.0 extensions documented in the section "Identity API v2.0 extensions" in the OpenStack API Complete Reference.

3   Heat Plugins

The required properties and resource types related to Heat are implemented as a plugins. The properties required for Ericsson-specific tags are added in the plugins.

The plugins are implemented as Python modules and are described in Section 3.1, and Section 3.2.

Installation and Configuration

The file /etc/heat/heat.conf contains a list of directories where the plugins are stored. To define additional directories, use the plugin_dirs option in file /etc/heat/heat.conf.

By default the /usr/lib/python2.7/dist-packages/heat/plugins directory is included and searched for plugins.

To install a plugin, copy the Python modules to one of the configured plugin directories.

Note:  

The Heat engine must be restarted after this in order to load the new plugins.

3.1   Ericsson::Heat::DelayPolicy

Note:  

This plugin is deprecated in this release of CEE, use OS::Heat::TestResource instead.

The plugin enables the use of a Delay Policy, as a resource in a Heat template. The Python module for the plugin is delay.py.

The resource enables delay in seconds between allocation of two consequent resources. A typical usage of this resource is waiting for one VM to finish configuring itself before invoking deployment of another one.

The new resource has the type Ericsson::Heat::DelayPolicy with the properties shown in Table 1.

An Ericsson::Heat::DelayPolicy resource uses the properties in Table 1 to dynamically create a delay between two resources, as shown in Example 1.

```yaml
heat_template_version: 2013-05-23
description:  Heat DelayPolicy creation example
resources:
  test_delay:
    type: Ericsson::Heat::DelayPolicy
    properties: {delay: 2}
```

3.2   Ericsson::Neutron::Port

Note:  

This plugin is deprecated in this release of CEE.

The plugin enables the use of port, as a resource in a Heat template. The Python module for the plugin is eport.py.

The new resource has the type Ericsson::Neutron::Port with the properties shown in Table 2.

An Ericsson::Neutron::Port resource uses the properties in Table 2 to dynamically create a port, as shown in Example 2.

```yaml
heat_template_version: 2013-05-23
description:  Heat Port creation example
resources:
  test_eport:
    type: Ericsson::Neutron::Port
    properties:
      network_id: net1234
      trunkport: {
        type: subport,
        parent_id: s0e951a6-h6b4-3f4c-8c88-b95e2a120b7m',
        vid: 101
                 }
```

3.3   Ericsson::Neutron::RouterInterface

This is a resource representation of an internal network interface to the specified router.

The new resource has the type Ericsson::Neutron::RouterInterface with the properties shown in Table 3.

An Ericsson::Neutron::RouterInterface resource uses the properties in Table 3, as shown in Example 3, using HOT syntax.

heat_template_version: 2013-05-23
...
resources:
  ...
  the_resource:
    type: OS::Neutron::RouterInterface
    properties:
      port: String
      router: String
      subnet: String
      active_device_id: String

4   Limitations and Recommendations

This section describes CEE specific limitations and recommendations.

4.1   Limitations

Not applicable.

4.2   Recommendations

Not applicable.