OpenStack SDK

The openstack.load_balancer.v2.amphora module provides access to Amphora-related resources. Amphora is the underlying implementation for Octavia load balancers. You can interact with these resources using the following classes, all of which inherit from openstack.resource.Resource:

• Amphora: Represents an Amphora instance.
• AmphoraConfig: Manages configuration settings for Amphora.
• AmphoraFailover: Manages failover configurations for Amphora.

A Node is a logical object managed by the Senlin service.

Key constraints and behaviors:

• Cluster Membership: A node can be a member of at most one cluster at any time.
• Orphan Nodes: A node that does not belong to any cluster is considered an 'orphan node'.
• Immutability: Most node properties are immutable once created, with the exception of name and params.

The Baremetal Introspection high-level interface is accessed through the baremetal_introspection attribute of an openstack.connection.Connection object. Note that the baremetal_introspection member is only attached to the Connection object if the service is detected during connection initialization.

import openstack

conn = openstack.connect(cloud='my-cloud')
# The baremetal_introspection proxy is available if the service is detected
introspection = conn.baremetal_introspection

When contributing to or extending the OpenStack SDK, follow PEP 8 standards for naming:

• Module names: Lowercase, underscore-separated (e.g., openstack.object_store).
• Class names: Capitalized (PascalCase) with no spaces (e.g., ServerMetadata).
• Attributes and methods: Lowercase, underscore-separated (e.g., allow_list, get_data).

Service Naming: Services are named after their program name rather than their code name. For example, use compute instead of Nova within the SDK.

Each service implements a Proxy class (located in openstack/<program_name>/vX/_proxy.py) which inherits from openstack.proxy.Proxy.

The Proxy acts as a convenience layer between the user and the low-level Resource objects. Instead of interacting with Adapter objects directly, you call methods on the Proxy which internally execute the corresponding Resource methods.

Example of a Proxy method implementation:

def list_flavors(self, **params):
    return flavor.Flavor.list(self.session, **params)

The OpenStack SDK is organized into a hierarchical structure that moves from low-level resource management to high-level connection handling:

1. Resource: The fundamental building block. Resource objects map directly to REST API endpoints (e.g., /servers). They handle CRUD operations, URL construction, and attribute mapping.
2. Proxy: A service-specific layer (e.g., openstack/compute/v2/_proxy.py) that provides a high-level interface. Instead of managing low-level Adapter and Resource objects manually, users interact with Proxy methods which wrap Resource operations.
3. Connection: The primary entry point for users. A Connection object manages the underlying connection details and exposes the various service Proxy objects.

In OpenStack SDK, a Resource is composed of three primary components that define how an object is identified and interacted with via the API:

1. URI: Represents the unique identifier/path for the resource within the OpenStack service.
2. Header: Manages the HTTP headers associated with requests for this resource.
3. Body: Represents the payload or data content of the resource.

These components work together to encapsulate the full state and identity of a cloud resource.