OpenStack Providers

Adding OpenStack Providers

Infrastructure Automation supports operating with the OpenStack admin tenant. When creating an OpenStack provider in Infrastructure Automation, select the OpenStack provider’s admin user because it is the default administrator of the OpenStack admin tenant. When using the admin credentials, a user in Infrastructure Automation provisions into the admin tenant, and sees images, networks, and instances that are associated with the admin tenant.

Note:

In OpenStack, you must add admin as a member of all tenants that users want to access and use in Infrastructure Automation.

See Cloud Tenants in Managing Infrastructure and Inventory for information on working with OpenStack tenants (projects) in Infrastructure Automation.

When adding an OpenStack cloud or infrastructure provider, enable tenant mapping in Infrastructure Automation to map any existing tenants from that provider.

This means Infrastructure Automation will create new cloud tenants to match each existing OpenStack tenant; each new cloud tenant and its corresponding OpenStack tenant will have identical resource assignments (including user and role synchronization) with the exception of quotas. Tenant quotas are not synchronized between Infrastructure Automation and OpenStack, and are available for reporting purposes only. You can manage quotas in Infrastructure Automation but this will not affect the quotas created in OpenStack.

During a provider refresh, Infrastructure Automation will also check for any changes to the tenant list in OpenStack. Infrastructure Automation will create new cloud tenants to match any new tenants, and delete any cloud tenants whose corresponding OpenStack tenants no longer exist. Infrastructure Automation will also replicate any changes to OpenStack tenants to their corresponding cloud tenants.

If you leave tenant mapping disabled, Infrastructure Automation will not create cloud tenants or tenant object hierarchy from OpenStack.

Note:

You can set whether Infrastructure Automation should use the Telemetry service or Advanced Message Queueing Protocol (AMQP) for event monitoring. If you choose Telemetry, you should first configure the ceilometer service on the overcloud to store events. See Configuring the Overcloud to Store Events for instructions.

For more information, see OpenStack Telemetry (ceilometer) in the Red Hat OpenStack Platform Architecture Guide.

Note:

To authenticate the provider using a self-signed Certificate Authority (CA), configure the Infrastructure Automation appliance to trust the certificate using the steps in Using a Self-Signed CA Certificate before adding the provider.

  1. Browse to menu: Compute > Clouds > Providers.

  2. Click Configuration, then click 1862 (Add a New Cloud Provider).

  3. From the Type list, select OpenStack.

  4. Enter a Name for the provider.

  5. Select the appropriate Zone for the provider. By default, the zone is set to default.

    Note:

    For more information, see the definition of host aggregates and availability zones in OpenStack Compute (nova) in the Red Hat OpenStack Platform Architecture Guide.

  6. Enter the OpenStack region in Provider Region.

  7. (Optional) Select an associated Openstack Infra Provider

  8. Select the appropriate API Version from the list. The default is Keystone v2.

    If you select Keystone v3, enter the Keystone V3 Domain ID that Infrastructure Automation should use. This is the domain of the user account you will be specifying later in the Default tab. If domains are not configured in the provider, enter default.

    Note:

    Keystone API v3 is required to create cloud tenants on OpenStack cloud providers.

    Note:

    • With Keystone API v3, domains are used to determine administrative boundaries of service entities in OpenStack. Domains allow you to group users together for various purposes, such as setting domain-specific configuration or security options. For more information, see OpenStack Identity (keystone) in the Red Hat OpenStack Platform Architecture Guide.
  1. (Optional) Enable tenant mapping by toggling the Tenant Mapping Enabled option to Yes. This synchronizes resources and users between the OpenStack cloud provider and Infrastructure Automation. By default, tenant mapping is disabled.

  2. In the Default tab, under Endpoints, configure the host and authentication details of your OpenStack provider:

    1. Select a Security Protocol method to specify how to authenticate the provider:

      • SSL without validation: Authenticate the provider insecurely using SSL.

      • SSL: Authenticate the provider securely using a trusted Certificate Authority. Select this option if the provider has a valid SSL certificate and it is signed by a trusted Certificate Authority. No further configuration is required for this option. This is the recommended authentication method.

      • Non-SSL: Connect to the provider insecurely using only HTTP protocol, without SSL.

    2. In Hostname (or IPv4 or IPv6 address), enter the public IP or fully qualified domain name of the OpenStack Keystone service.

      Note:

      The hostname required here is also the OS_AUTH_URL value in the ~/overcloudrc file generated by the director (see Accessing the Overcloud in Red Hat OpenStack Platform Director Installation and Usage), or the ~/keystonerc_admin file generated by Packstack (see Evaluating OpenStack: Single-Node Deployment).

    3. In API Port, set the public port used by the OpenStack Keystone service. By default, OpenStack uses port 5000 for non-SSL security protocol. For SSL, API port is 13000 by default.

    4. In the Username field, enter the name of a user in the OpenStack environment.

      In environments that use Keystone v3 authentication, the user must have the **admin** role for the relevant domain.
    5. In the Password field, enter the password for the user.

    6. Click Validate to confirm Infrastructure Automation can connect to the OpenStack provider.

  3. Next, configure how Infrastructure Automation should receive events from the OpenStack provider. Click the Events tab in the Endpoints section to start.

    • To use the Telemetry service of the OpenStack provider, select Ceilometer. Before you do so, the provider must first be configured accordingly. See Configuring the Overcloud to Store Events for details.

    • If you prefer to use the AMQP Messaging bus instead, or eventing is not enabled on Ceilometer, select AMQP and configure the following:

      1. Select a Security Protocol method.

      2. In Hostname (or IPv4 or IPv6 address) (of the Events tab, under Endpoints), enter the public IP or fully qualified domain name of the AMQP host.

      3. In the API Port, set the public port used by AMQP. By default, OpenStack uses port 5672 for this.

      4. In the Username field, enter the name of an OpenStack user with privileged access (for example, admin). Then, provide its corresponding password in the Password field.

      5. Click Validate to confirm the credentials.

  4. Click Add after configuring the cloud provider.

Note:

Configuring the Overcloud to Store Events

By default, the Telemetry service does not store events emitted by other services in a Red Hat OpenStack Platform environment. The following procedure outlines how to enable the Telemetry service on your OpenStack cloud provider to store such events. This ensures that events are exposed to Infrastructure Automation when a Red Hat OpenStack Platform environment is added as a cloud provider.

  1. Log in to the undercloud host.

  2. Create an environment file called ceilometer.yaml, and add the following contents:

    parameter_defaults:
      CeilometerStoreEvents: true
    
  3. Please see the below NOTE.

If your OpenStack cloud provider was not deployed through the undercloud, you can also set this manually. To do so:

  1. Log in to your Controller node.

  2. Edit /etc/ceilometer/ceilometer.conf, and specify the following option:

    store_events = True
    

Note:

Passing the newly created environment file to the overcloud deployment is environment specific and requires executing commands in particular order depending on use of variables. For further information please see Director Installation and Usage in the Red Hat OpenStack Platform documentation.