Red Hat Training

A Red Hat training course is available for Red Hat CloudForms

Chapter 4. Cloud Providers

In CloudForms, a cloud provider is a cloud computing environment that you can add to a CloudForms appliance to manage and interact with the resources in that environment. This chapter describes the different types of cloud providers that you can add to CloudForms, and how to manage them. Most cloud providers are added individually to CloudForms. Additionally, Amazon EC2 and Azure cloud providers can be discovered automatically by CloudForms.

The web interface uses virtual thumbnails to represent cloud providers. Each thumbnail contains four quadrants by default, which display basic information about each provider:

Cloudthumbnail

  1. Number of instances
  2. Management system software
  3. Number of images
  4. Authentication status

Table 4.1. Provider authentication status

IconDescription

2190

Validated: Valid authentication credentials have been added.

2191

Invalid: Authentication credentials are invalid.

2192

Unknown: Authentication status is unknown or no credentials have been entered.

4.1. OpenStack Providers

4.1.1. Adding OpenStack Providers

Red Hat CloudForms supports operating with the OpenStack admin tenant. When creating an OpenStack provider in Red Hat CloudForms, 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 Red Hat CloudForms 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 CloudForms.

See Tenancy in the Deployment Planning Guide for more details on tenancy in CloudForms.

When adding an OpenStack cloud or infrastructure provider, you can enable tenant mapping in CloudForms to map any existing tenants from that provider. This means CloudForms will create new cloud tenants to match each existing OpenStack tenant; each new cloud tenant and its corresponding OpenStack tenant will have identical resources assignments, with the exception of quotas. Tenant quotas are not synchronized between CloudForms and OpenStack, and are available for reporting purposes only. You can manage quotas in CloudForms but this will not affect the quotas created in OpenStack.

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

Note

You can set whether Red Hat CloudForms 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 Section 4.1.1.1, “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 CloudForms appliance to trust the certificate using the steps in Section A.1, “Using a Self-Signed CA Certificate” before adding the provider.

  1. Navigate to Compute → Clouds → Providers.
  2. Click 1847 (Configuration), then click 1862 (Add a New Cloud Provider).
  3. Enter a Name for the provider.
  4. From the Type list, select OpenStack.

  5. 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 Red Hat CloudForms 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.
    • The provider you are creating will be able to see projects for the given domain only. To see projects for other domains, add it as another cloud provider. For more information on domain management in OpenStack, see Domain Management in the Red Hat OpenStack Platform Users and Identity Management Guide.
  6. Enter a region number in Region.
  7. Enter the appropriate Zone for the provider. If you do not specify a zone, it is set to default.
  8. By default, tenant mapping is disabled. To enable it, set Tenant Mapping Enabled to Yes.

  9. 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.

  10. 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.

      Important

      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 Red Hat CloudForms can connect to the OpenStack provider.

  11. Next, configure how Red Hat CloudForms 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 Section 4.1.1.1, “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.
  12. Click Add after configuring the cloud provider.
Note
  • To collect inventory and metrics from an OpenStack environment, the Red Hat CloudForms appliance requires that the adminURL endpoint for the OpenStack environment be on a non-private network. Hence, the OpenStack adminURL endpoint should be assigned an IP address other than 192.168.x.x. Additionally, all the Keystone endpoints must be accessible, otherwise refresh will fail.
  • Collecting capacity and utilization data from an OpenStack cloud provider requires selecting the Collect for All Clusters option under Configuration, in the settings menu. For information, see Capacity and Utilization Collections in the General Configuration Guide.

4.1.1.1. 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 Red Hat CloudForms 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.

4.2. Azure Providers

4.2.1. Adding Azure Providers

Red Hat CloudForms supports Microsoft Azure providers. Before CloudForms can be authenticated to Microsoft Azure, you must complete a series of prerequisite steps using the Azure portal; see Create Active Directory application and service principal account using the Azure portal. Follow the steps to set up an Azure Active Directory (Azure AD) and assign the required permissions to it, then create an Azure Active Directory application, and obtain the Application ID (Client ID), Directory ID (Tenant ID), Subscription ID, and Key Value (Client Key) that are required to add and connect to the Azure instance as a provider in CloudForms. Currently, all of these steps can be performed using either the Azure Resource Manager or Service Manager (Classic) mode.

Note

In the steps described in Create Active Directory application and service principal account using the Azure portal:

  • The Application ID obtained during Get Application ID and Authentication Key is your Client ID. In the same section, after providing a description and a duration for the key, the VALUE displayed after clicking Save is your Client Key. If you choose an expiring key, make sure to note the expiration date, as you will need to generate a new key before that day in order to avoid an interruption.
  • The Directory ID obtained during Get Tenant ID is your Tenant ID. In Azure Active Directory (Azure AD), a tenant is a dedicated instance of the Azure AD service and is representative of an organization. It houses the users in a company and the information about them - their user profile data, permissions, groups, applications, and other information related to an organization and its security. To allow Azure AD users to sign in to your application, you must register your application in a tenant of your own which is assigned a Tenant ID (Directory ID).
  • During Assign Application to Role, select the Contributor role and not the Reader role.
  • To obtain your Subscription ID, log in to the Azure portal and click Subscriptions on the slide-out menu on the left. Find the appropriate subscription and see your Azure Subscription ID associated with it. Note that if the Subscriptions tab is not visible, then click on More services > to find it. The Azure Subscription ID is like a billing unit for all of the services consumed in your Azure account, including virtual machines and storage. The Subscription ID is in the form of a Globally Unique Identifier (GUID).

So, after a service principal account (instance of an application in a directory) has been created using the Azure portal, the following four pieces of information will be available within the Azure AD module.

  • Directory ID (Tenant ID)
  • Subscription ID
  • Application ID (Client ID)
  • Client Key

You can now use these values in the procedure below to add an Azure cloud instance as a provider to CloudForms.

To Add an Azure Cloud Provider:

  1. Navigate to Compute → Clouds → Providers.
  2. Click 1847 (Configuration), then click 1862 (Add a New Cloud Provider).
  3. Enter a Name for the provider.
  4. From the Type list, select Azure.
  5. Select a region from the Region list. One provider will be created for the selected region.
  6. Enter Tenant ID.
  7. Enter Subscription ID.
  8. Enter Zone.
  9. In the Credentials section, enter the Client ID and Client Key; click Validate.
  10. Click Add.

4.2.2. Discovering Azure Providers

Red Hat CloudForms provides the ability to discover a set of Microsoft Azure providers across all regions.

  1. Navigate to Compute → Clouds → Providers.
  2. Click Configuration (Configuration), then click Discover Cloud Providers (Discover Cloud Providers).
  3. Select Azure from the Discover Type list.
  4. In the Credentials section, enter your Azure Client ID, Client Key, Azure Tenant ID, and the Subscription ID for that tenant.
  5. Click Start.

4.2.3. Disabling Azure Cloud Regions

Red Hat CloudForms allows administrators to disable Azure cloud regions on the appliance server. You can use this capability to disable certain classified regions. Once disabled, the region will not be available when adding a new Azure provider.

  1. From the settings menu, select Configuration.
  2. Click on the Settings accordion, then click Zones.
  3. Click the zone where the CloudForms server is located, then click on the EVM server.
  4. Click on the Advanced tab.

  5. Search for :ems_azure:, and enter the regions you want to disable under :disabled_regions:. 

    Example. To disable the `us-gov-arizona` and `us-gov-texas` regions:

:ems_azure:
  :disabled_regions:
  - us-gov-arizona
  - us-gov-texas
  6. Click Save.

4.3. Amazon EC2 Providers

4.3.1. Permissions for Amazon EC2 Providers

Red Hat recommends using Amazon EC2’s Power User Identity and Access Management (IAM) policy when adding Amazon EC2 as a cloud provider in CloudForms. This policy allows those in the Power User group full access to AWS services except for user administration, meaning a CloudForms API user can access all of the API functionality, but cannot access or change user permissions.

Note

When adding an Amazon EC2 provider in CloudForms with the intention to use the SmartState analysis feature, Red Hat recommends assigning Admin group privileges. For situations in which assigning the Admin group is unacceptable, manually create an Amazon EC2 policy role using specific permissions. See Section 4.3.1.1, “Manually Creating an Amazon EC2 Role” for more information.

Further limiting API access limitations can limit Automate capabilities, as Automate scripts directly access the AWS SDK to create brand new application functionality.

The AWS services primarily accessed by the CloudForms API include:

  • Elastic Compute Cloud (EC2)
  • CloudFormation
  • CloudWatch
  • Elastic Load Balancing
  • Simple Notification Service (SNS)
  • Simple Queue Service (SQS)

4.3.1.1. Manually Creating an Amazon EC2 Role

To eliminate the need to assign Admin group privileges to the Amazon EC2 provider, create an IAM role following the procedure described in Creating a Role for an AWS Service (Console) in the Amazon Web Services documentation.

Use the following parameters:

  1. Select EC2 as the service the role will use.

  2. Attach the following permissions:

    1. AmazonEC2FullAccess
    2. AmazonS3FullAccess
    3. AmazonSQSFullAccess
  3. Enter smartstate for the Role name.

Once the IAM role is created, assign the provider Power User privileges as described in Section 4.3.1, “Permissions for Amazon EC2 Providers”.

4.3.2. Adding Amazon EC2 Providers

Complete the following procedure to add an Amazon EC2 cloud provider in CloudForms.

  1. Navigate to Compute → Clouds → Providers.
  2. Click 1847 (Configuration), then click 1862 (Add a New Cloud Provider).
  3. Enter a Name for the provider.
  4. From the Type list, select Amazon EC2.
  5. Select a Region.
  6. Select the appropriate Zone if you have more than one available.

  7. Under Endpoints, click the Default tab.

    1. Generate an Access Key in the Security Credentials of your Amazon AWS account. The Access Key ID acts as your User ID, and your Secret Access Key acts as your Password.
    2. Click Validate to validate the credentials.

  8. Click the SmartState Docker tab.

    1. Enter the SmartState Docker User Name and SmartState Docker Password. Here use your registry.access.redhat.com credentials required to perform SmartState analysis on AWS. These credentials are required so that you can pull the image from the Red Hat docker registry.
  9. Click Add.

4.3.3. Discovering Amazon EC2 Cloud Providers

Red Hat CloudForms provides the ability to discover cloud providers associated with a particular set of Amazon EC2 account details.

  1. Navigate to Compute → Clouds → Providers.
  2. Click Configuration (Configuration), then click Discover Cloud Providers (Discover Cloud Providers).
  3. Select Amazon EC2 from the Discover Type list.
  4. Enter your Amazon EC2 User ID and Password. Reenter your password in the Verify Password field.
  5. Click Start.

4.3.4. Enabling Public AMIs from Amazon EC2

By default, public AMIs from an Amazon EC2 provider are not viewable in Red Hat CloudForms. To make these images viewable, you must edit the main configuration file for the appliance.

Note

Syncing all public images may require additional memory resources. Also, bear in mind that syncing happens in each configured Amazon EC2 provider, which will require a similar amount of total memory resources.

  1. Navigate to the settings menu, then Configuration → Zone → Advanced.
  2. Select the configuration file to edit from the File list. If not already automatically selected, select EVM Server Main Configuration.

  3. Set the get_public_images parameter:

    1. Set the parameter to get_public_images: true to make public images viewable.
    2. Set the parameter to get_public_images: false to make public images not viewable.
  4. Optionally, configure an array of filters in public_images_filters to restrict which images are synced. See http://docs.aws.amazon.com/sdkforruby/api/Aws/EC2/Client.html#describe_images-instance_method for more details.

4.3.5. Enabling AWS Config Notifications

Amazon’s AWS Config notifies subscribers of changes in a region through its Simple Notification Service (SNS). Red Hat CloudForms subscribes to the SNS service for AWS Config deltas and converts the deltas into CloudForms events.

  1. Enable the AWS Config service in the AWS Management Console. See the AWS Config Developer Guide for more information.
  2. Create a new Amazon SNS topic named AWSConfig_topic. CloudForms automatically connects to this topic.
  3. (Optional) Configure the frequency of delta creation in the AWS Management Console.

You can assign CloudForms policies to the AWS events listed below. The appliance performs a provider refresh on all these events except for AWS_EC2_Instance_UPDATE.

EventPoliciesRefresh

AWS_EC2_Instance_CREATE

src_vm

vm_create

ems

AWS_EC2_Instance_UPDATE

N/A

ems

AWS_EC2_Instance_running

src_vm

vm_start

ems

AWS_EC2_Instance_stopped

src_vm

vm_power_off

ems

AWS_EC2_Instance_shutting-down

src_vm

vm_power_off

ems

4.3.6. Enabling Amazon EC2 Events

After adding an Amazon EC2 provider and configuring an SNS topic in Section 4.3.5, “Enabling AWS Config Notifications”, create a CloudTrail, then configure CloudWatch rules on your EC2 provider to automatically get events in CloudForms for monitoring the provider.

Note

The following procedures are accurate at time of publishing. See the Amazon AWS documentation for further details on these steps.

4.3.6.1. Creating a CloudTrail

In the CloudTrail area of the AWS Management Console, create a trail and an S3 bucket:

  1. Create a Trail with a custom name.
  2. (Optional) If you want to apply the trail to all of your CloudForms regions, select Yes for Apply trail to all regions.
  3. For Management Events, select Read/Write events: All.
  4. Create a new S3 bucket.

4.3.6.2. Creating CloudWatch Rules Based on Event Patterns

In the CloudWatch area of the AWS Management Console, create three rules: one rule each for EC2, volumes, and snapshots.

Important

When an SNS topic is deleted and recreated (manually or by CloudForms), CloudWatch rules must be recreated as well, even though the SNS target topic for CloudWatch rules appears to be assigned to these rules. The CloudWatch rule does not send events to this recreated topic until it is recreated too.

To create a CloudWatch rule for EC2:

  1. Navigate to Events → Rules and click Create rule.
  2. Select the Event Pattern radio button to specify the event source.

  3. Edit the Event Pattern Preview box, and paste and save the following code to create a rule based on a custom event pattern: 

    {
  "source": [
    "aws.ec2"
  ],
  "detail-type": [
    "AWS API Call via CloudTrail"
  ],
  "detail": {
    "eventSource": [
      "ec2.amazonaws.com"
    ]
  }
}

  4. Click Add target and specify the following attributes:

    • Type: SNS Topic
    • Topic: AWSConfig_topic
    • Input: Matched event
  5. Click Configure Details to save these details.
  6. Configure a name and description for the rule if desired. Ensure the Enabled checkbox is selected for State.
  7. Click Create rule to save the CloudWatch rule.

Repeat the same procedure to create a CloudWatch rule for volumes, pasting the code snippet below to the Event Pattern Preview box:

  1. Navigate to Events → Rules and click Create rule.
  2. Select the Event Pattern radio button to specify the event source.

  3. Edit the Event Pattern Preview box, and paste and save the following code to create a rule based on a custom event pattern: 

    {
  "source": [
    "aws.ec2"
  ],
  "detail-type": [
    "EBS Volume Notification"
  ]
}

  4. Click Add target and specify the following attributes:

    • Type: SNS Topic
    • Topic: AWSConfig_topic
    • Input: Matched event
  5. Click Configure Details to save these details.
  6. Configure a name and description for the rule if desired. Ensure the Enabled checkbox is selected for State.
  7. Click Create rule to save the CloudWatch rule.

Repeat the same procedure to create a CloudWatch rule for snapshots, pasting the code snippet below to the Event Pattern Preview box:

  1. Navigate to Events → Rules and click Create rule.
  2. Select the Event Pattern radio button to specify the event source.

  3. Edit the Event Pattern Preview box, and paste and save the following code to create a rule based on a custom event pattern: 

    {
  "source": [
    "aws.ec2"
  ],
  "detail-type": [
    "EBS Snapshot Notification"
  ]
}

  4. Click Add target and specify the following attributes:

    • Type: SNS Topic
    • Topic: AWSConfig_topic
    • Input: Matched event
  5. Click Configure Details to save these details.
  6. Configure a name and description for the rule if desired. Ensure the Enabled checkbox is selected for State.
  7. Click Create rule to save the CloudWatch rule.

EC2 can now automatically refresh events in CloudForms.

4.3.7. Disabling Amazon Cloud Regions

Red Hat CloudForms allows administrators to disable Amazon cloud regions on the appliance server. Use this capability to disable certain classified regions like AWS GovCloud. Once disabled, the region will not be available when adding an Amazon EC2 provider.

  1. From the settings menu, select Configuration.
  2. Click on the Settings accordion, then click Zones.
  3. Click the zone where the CloudForms server is located, then click on the EVM server.
  4. Click on the Advanced tab.

  5. Search for :ems_amazon:, and enter the regions you want to disable under :disabled_regions:. 

    Example. To disable the `ap-northeast-1` region:

:ems_amazon:
  :disabled_regions:
  - us-gov-west-1
  - ap-northeast-1
  6. Click Save.
Note

In AWS, Government regions are disabled by default. To enable a disabled region, be sure to do so in the production.yml configuration file manually.

4.4. Google Compute Engine Providers

4.4.1. Adding Google Compute Engine Providers

After initial installation and creation of a Red Hat CloudForms environment, add a Google Compute Engine provider by following this procedure.

Prerequisites

To add a Google Compute Engine provider to Red Hat CloudForms, you need:

  • A Google Cloud Platform account
  • A Google Compute Engine project with the Google Compute Engine API enabled

  • A service account JSON key for your project

    Note

    You can generate a private JSON key for your project in IAM & Admin → Service Accounts in Google Cloud Platform. This key is used to authenticate against your provider.

    For additional information, see the Google Cloud Platform documentation at https://cloud.google.com/storage/docs/authentication.

To add a Google Compute Engine provider:

  1. Navigate to Compute → Clouds → Providers.
  2. Click 1847 (Configuration), then click 1862 (Add a New Cloud Provider).
  3. Enter a Name for the provider.
  4. From the Type list, select Google Compute Engine.
  5. Select your Preferred Region from the list.
  6. Enter your Google Compute Engine Project ID for Project.
  7. Select the appropriate Zone if you have more than one available. Red Hat recommends creating a new zone for your Google Compute Engine provider.
  8. Copy your project’s Service Account JSON key contents to the Service Account JSON field.
  9. Click Validate to validate the credentials.
  10. Click Add.
Note

Make sure that NTP synchronization is enabled and working. When clocks are not synchronized, the following error will be raised:

Credential validation was not successful: Authorization failed. Server message: { "error" : "invalid_grant", "error_description" : "Invalid JWT: Token must be a short-lived token and in a reasonable timeframe" }

4.4.2. Enabling Google Compute Engine Events

After adding Google Compute Engine as a provider in Red Hat CloudForms, enable events for the provider so that you can monitor the system from Red Hat CloudForms.

Events are set up on a per-project basis by using Google Stackdriver logging combined with Google Pub/Sub. Stackdriver logging is a service that aggregates and exposes log events from Google services and applications. Stackdriver exports the log events to Google Pub/Sub, a messaging service. This section describes how to export activity log entries for a Google Compute Engine project so that events are captured in Red Hat CloudForms.

Prerequisites for Exporting Google Compute Engine Events

  • You must have owner permission on the project you are exporting.
  • The Google Cloud Pub/Sub API must be enabled for your project. To enable the API:
  1. In Google Cloud Platform, select your project from the top menu bar.
  2. Click GCE products services to show the Products and Services menu. Click API Manager to go to https://console.cloud.google.com/apis/library/.
  3. In the API Manager Overview tab, search for Pub/Sub in the Google APIs search bar and select Google Cloud Pub/Sub API from the results. Click the Enable button.
  4. If Google Cloud Pub/Sub API is already enabled, the Enable button will not show, and instead Google Cloud Pub/Sub API will be listed under Enabled APIs.
  • The Stackdriver logging service must have permission to publish to your project’s Pub/Sub service. To add the required permissions:
  1. In Google Cloud Platform, select your project and navigate to GCE products services Products and Services → IAM & Admin → IAM to go to https://console.cloud.google.com/iam-admin/iam/.

  2. Assign Logs Configuration Writer permissions to your project:

    1. If the cloud-logs@system.gserviceaccount.com account is already listed under Members, ensure Logs Configuration Writer is selected under Role(s).

    2. If the cloud-logs@system.gserviceaccount.com account is not listed under Members:

      1. Click Add to add the permissions.
      2. In the dialog box, enter cloud-logs@system.gserviceaccount.com in Members to add the Google APIs service account to the permissions list.
      3. In the Select a Role dropdown, select Logging → Logs Configuration Writer and click Add.

4.4.2.1. Configuring Google Compute Engine to Export Events

After you have completed the steps from Prerequisites for Exporting Google Compute Engine Events, set up your Google Compute Engine project to export events to Red Hat CloudForms with the following steps:

  1. In Google Cloud Platform, click GCE products services to show the Products and Services menu, and click Logging to go to https://console.cloud.google.com/logs/.
  2. Select your project from the top menu bar.
  3. Click Exports from the Logging menu.
  4. In the Select service list, select Compute Engine.
  5. Under Export these sources, click Add item, and select compute.googleapis.com/activity_log from the list.
  6. Under Select export destinations, click the Publish to Cloud Pub/Sub topic dropdown and click Add new topic…​

  7. In the Create Cloud Pub/Sub Topic dialog, enter manageiq-activity-log as the Name. Click Create.

    GCE exports

  8. Click Save.

When changes occur to Google Compute Engine instances, Red Hat CloudForms is now notified and reports these changes as events.

Note

For additional information about Google Compute Engine, see the Google Cloud Platform documentation:

4.4.2.2. Viewing Google Compute Engine Events in Red Hat CloudForms

In Red Hat CloudForms, view events for your Google Compute Engine project by following these steps:

  1. Navigate to Compute → Clouds → Providers and select your Google Compute Engine project.
  2. Click Monitoring → Timelines on the provider summary page to see an events timeline for the project.

4.5. Refreshing Cloud Providers

Refresh a cloud provider to find other resources related to it. Ensure the chosen cloud providers have the correct credentials before refreshing.

  1. Navigate to Compute → Clouds → Providers.
  2. Select the checkboxes for the cloud providers to refresh.
  3. Click Configuration (Configuration), and then Refresh Relationships and Power States (Refresh Relationships and Power States).
  4. Click OK.

4.6. Tagging Cloud Providers

Apply tags to all cloud providers to categorize them together at the same time.

  1. Navigate to Compute → Clouds → Providers.
  2. Select the checkboxes for the Cloud Providers to tag.
  3. Click Policy (Policy), and then Edit Tags (Edit Tags).

  4. Select a customer tag to assign from the first list.

    2219

  5. Select a value to assign from the second list.
  6. Click Save.

4.7. Removing Cloud Providers

A cloud provider might require removal from the VMDB if it is no longer in use.

  1. Navigate to Compute → Clouds → Providers.
  2. Check the cloud providers to remove.
  3. Click Configuration (Configuration), and then Remove Cloud Providers from the VMDB (Remove Cloud Providers from the VMDB).
  4. Click OK.

4.8. Editing a Cloud Provider

Edit information about a provider such as the name, IP address, and login credentials.

Note

The Type value is unchangeable.

To use a different cloud provider, create a new one.

  1. Navigate to Compute → Clouds → Providers.
  2. Click the cloud provider to edit.
  3. Click Configuration (Configuration), and then Edit Selected Cloud Provider (Edit Selected Cloud Provider).
  4. Edit the Basic Information. This varies depending on the Type of provider.

  5. Fill out the Credentials by typing in a Username, Password, and a verification of this password (Confirm Password).

    • If selecting Amazon EC2, generate an Access Key in the Security Credentials of your Amazon AWS account. The Access Key ID acts as your User ID, and your Secret Access Key acts as your Password.
    • If selecting OpenStack, use the Keystone User ID and Password for your login credentials.
  6. If editing an OpenStack provider, use the AMQP subtab to provide credentials required for the Advanced Message Queuing Protocol service on your OpenStack Nova component.
  7. Click Validate and wait for notification of successful validation.
  8. Click Save.

4.9. Viewing a Cloud Provider’s Timeline

View the timeline of events for instances registered to a cloud provider.

  1. Navigate to Compute → Clouds → Providers.
  2. Click the desired cloud provider for viewing the timeline.
  3. Click Monitoring (Monitoring), and then Timelines (Timelines).

  4. From Options, customize the period of time to display and the types of events to see.

    • Use Show to select regular Management Events or Policy Events.
    • Use the Type list to select hourly or daily data points.
    • Use Date to type the date for the timeline to display.
    • If you select to view a daily timeline, use Show to set how many days back to go. The maximum history is 31 days.
    • The three Event Groups list allow you to select different groups of events to display. Each has its own color.
    • From the Level list, select a Summary event, or a Detail list of events.