Configuring OpenStack Observer jobs

Using the OpenStack Observer, you can configure jobs that dynamically load OpenStack data for analysis by Agile Service Manager.

Before you begin

Important: The OpenStack Observer supports the on-premise OpenStack versions Ocata, Pike, Rocky, Queens, Stein, Train, Zed and Antelope.

Ensure you have the OpenStack service details to hand, such as the parameters for its APIs or RabbitMQ message bus. If you are configuring a query job, have OpenStack location and authorisation details to hand. If you are configuring a rabbitmq job, you must also identify and provide access to the RabbitMQ message bus.

OpenStack installation requirements:
If you have installed OpenStack using DevStack, you must add the code specified here to the end of the local.conf file, and reinstall it. If you have installed OpenStack using another installation method, you must add the code specified here to the nova.conf file, and then restart the Nova (compute) service.
If you have already installed OpenStack using DevStack
Add the following code to the end of the local.conf file, and then reinstall OpenStack.
If you are planning to install OpenStack using DevStack
Add the following code to the end of the local.conf file before installation.
[[post-config|$NOVA_CONF]] 
[DEFAULT]
notification_topics = notifications,com.ibm.asm.obs.nova.notify
notification_driver=messagingv2 
notify_on_state_change=vm_and_task_state 
notify_on_any_change=True
For standard (or any other) OpenStack installations
Add the following code under the [DEFAULT] section of the nova.conf file, and then restart the Nova (compute) service.
notification_topics = notifications,com.ibm.asm.obs.nova.notify
notification_driver=messagingv2 
notify_on_state_change=vm_and_task_state 
notify_on_any_change=True
To enable port numbers for standard OpenStack installations
OpenStack assigns specific port numbers to each of its service. For Agile Service Manager to communicate with the OpenStack instance, you must enable the following default ports.
Tip: Check with your OpenStack administrator if custom port numbers have been configured.
Load jobs
Default ports:
  • KeyStone: 5000
  • Nova: 8774
  • Neutron: 9696
  • Glance: 9292
  • Cinder: 8776
  • Heat: 8004
Listen jobs
Default port:
  • RabbitMQ: 5672

The OpenStack Observer is installed as part of the core installation procedure.

Note: OpenStack uses RBAC-based protection of its API by defining policy rules based on an RBAC approach. Availability of resources retrieved by the observer is also governed by the same policy. For example, a VM created in project A by users with the admin role may only be available to other users with the same admin role. This can be configured or modified according to user requirements in the OpenStack's policy configuration.
Troubleshooting: A Certificate Chaining Error can occur when launching an OpenStack Observer job. See the following troubleshooting topic for more information: OpenStack Observer certificate chaining error

About this task

The OpenStack Observer jobs extract OpenStack resources via REST or RabbitMQ. The Observer loads and updates the resources and their relationships within the Netcool Agile Service Manager core topology service.

You configure and run the following two jobs.
Restapi Load job
A transient (one-off) job that loads all requested topology data from the OpenStack instance by REST API.
By default, these jobs are one-off, transient jobs that perform a full upload of all requested topology data as soon as they are triggered.
You can also run these jobs (again) manually from the Observer UI, or schedule them to run at set times when configuring them.
The job loads baseline topology data through the following OpenStack's APIs:
  • Keystone (identity)
  • Cinder (block storage)
  • Glance (image)
  • Heat (orchestration)
  • Neutron (network)
  • Nova (compute)
Restriction: An OpenStack environment that has a list of endpoints whereby the 'heat-cfn' service comes first (before the 'heat' service) will encounter a JSON parsing error recorded in the logs due to a known issue in the openstack4j library. When this happens, the full load for the heat service will be skipped entirely. Other services will run as normal.
Rabbitmq Listen job
A long-running job that reads messages on OpenStack's RabbitMQ message bus for activity from the Cinder (block storage), Heat (orchestration), Neutron (network) and Nova (compute) components continually, until it is explicitly stopped, or until the Observer is stopped.
The rabbitmq job should only be run after an initial restapi job has been completed.
Restriction: Only one rabbitmq job should be listening to one queue (or sets of queues) at any one time. If you need to listen to multiple projects, then separate queues must be set up in OpenStack, with appropriate names, before separate listening jobs are submitted for each. For example, for Nova via the rmq_nova_notify attribute, for Neutron via the rmq_neutron_notify attribute.
Important: You must specify the following properties consistently for both the restapi and rabbitmq jobs:
  • Data center name
  • OpenStack project name
  • OpenStack username

Procedure

To configure OpenStack Observer jobs

  1. On the Observer jobs page, perform one of the following actions:
    To edit an existing job
    Open the List of options overflow menu next to the job and click View & edit.
    To create a new job
    Click Add a new job + and select the OpenStack Observer tile.
  2. Configure the following parameters for the job, then click Save to save and run the job.
    Table 1. OpenStack Observer restapi job parameters
    Parameter Action Details
    Job type Select either restapi load or rabbitmq listen. Required
    Unique ID Enter a unique name for the job Required
    OpenStack authentication type Specify the OpenStack connection authentication technique to use. Required. Choose either v2_Tenant, v3_Unscoped, v3_Project, or v3_Domain.
    OpenStack password Specify the OpenStack password with which to authenticate. Required. Use plain text.
    OpenStack identity endpoint Specify the authentication URL. Required. Must include the port and version.
    Data center name Specify the name of the data center in which the OpenStack instance is running. Required. If more than one OpenStack instance is run, and duplicate project or tenant names exist, you must disambiguate them here.
    OpenStack username Specify the OpenStack user name to connect as (or to). Required
    OpenStack project name Specify the OpenStack project name, for example the value of OS_PROJECT_NAME. Multi project names must be separated by comma. Required
    OpenStack project domain name Specify the project domain name to use, for example the value of OS_PROJECT_DOMAIN_NAME Optional
    OpenStack user domain name Specify the user domain name to use, for example the value of OS_USER_DOMAIN_NAME Optional
    OpenStack region name Specify the OpenStack region, for example the value of OS_REGION_NAME. The value is case-sensitive. If it is not set, the default value is regionOne. Required for v3 authentication
    OpenStack perspective Select the URL perspective the API accesses data from. Optional. Choose from Admin, Public, and Internal.
    Connection and read timeout (ms) Choose the timeout setting for the connection and read actions. Optional. The default is 5000 (5 seconds).
    Optionally load hypervisors Choose whether to turn the loading of hypervisors on or off. This option requires the os_compute_api:os-hypervisors privilege granted by the OpenStack administrator. Optional. The default is false (off).
    Optionally load Host Aggregates Choose whether to turn the loading of Host Aggregates on or off. This option requires the os_compute_api:os-aggregates:index privilege granted by the OpenStack administrator. Optional. The default is false (off).
    SSL Verification Choose whether to use SSL verification (true or false). If false, HTTPS is used, but without hostname validation. Optional
    OpenStack host certificate Specify a certificate name to load into the trust store.
    Required. For more information, see Configuring observer job security.
    On-prem
    Create and store the certificate in the ASM_HOME/security directory.
    OCP
    Obtain the authentication certificate using OpenSSL and store it as a secret.
    SSL truststore file name Specify the trustStore file name.
    Tip: You can use the observer name (<observer>.jks) for example openstack.jks.
    		 Required. For both on-prem and OCP, provide the JKS name, and the observer will then create the JKS file accordingly.
    SSL truststore file password Specify a truststore file password. Required. Use plain text.
    Proxy username Specify the proxy username Optional
    Proxy password Specify the proxy password Optional
    Proxy host Specify the proxy host to connect via Optional
    Proxy port Specify the proxy port to connect via Optional. Default is 8080.
    Access scope

    Enter text to provide a scope for the resources.

    Access scope can help map alerts to resources when resources in different scopes share the same parameters, such as matchTokens.

    		 Optional.
    Tip: You can define access scope for locations, project names, namespaces, etc.
    Generate debug support file
    Set the optional Generate debug support file parameter to 'True' in order to capture the output of the next scheduled job run as a file. This file will be stored with an observer's log files and can be used to debug observer issues, for example at the request of your designated Support team, or while using a test environment. For one-off jobs (that is, Load jobs), this parameter reverts to 'False' after the next completed run. To examine the output produced, you can load the generated debug file using the File Observer. The file is saved to the following locations:
    On-prem
    $ASM_HOME/logs/<obs>-observer/
    On OCP
    /var/log/itsm/<obs>-observer
    		 Optional
    Observer job description Enter additional information to describe the job. Optional
    Job schedule

    Specify when the job should run, and whether it should run at regular intervals.

    By default the job runs immediately, and only once.

    Optionally you can specify a future date and time for the job to run, and then set it to run at regular intervals after that.

    Optional. Transient (one-off) jobs only.

    If you set a job schedule, the run intervals must be at least 90 seconds apart, and if you set them at less than 15 minutes, a warning is displayed, as the frequency can impact system performance.
    Table 2. OpenStack Observer rabbitmq job parameters
    Parameter Action Details
    Unique ID Enter a unique name for the job Required
    RabbitMQ username Specify the AMQP user name to connect to the broker. Required
    RabbitMQ password Specify the password to use to connect to the broker. Required. Use plain text.
    RabbitMQ hosts Enter a (comma-separated) list of hosts in the RabbitMQ cluster. Required. Add a comma-separated list of host(s) (for example, host1:5672,host2:5672) to connect to in the RabbitMQ cluster. The first host connected to successfully is used.
    Note: Use IP addresses instead of hostnames.
    Data center name Specify the name of the data center in which the OpenStack instance is running. Required. If more than one OpenStack instance is run, and duplicate project or tenant names exist, you must disambiguate them here.
    OpenStack username Specify the OpenStack user name to connect as (or to). Required
    OpenStack project name Specify the OpenStack project. Optional
    RabbitMQ virtual host name Specify the virtual host to connect to the broker. Optional
    Use SSL? Choose whether to use an SSL connection. Optional. Choose true or false. For RabbitMQ, you must choose true.
    Nova v2 Oslo message queue Specify the Nova v2 Oslo message queue. Optional
    Neutron v2 Oslo message queue Specify the Neutron v2 Oslo message queue. Optional
    Cinder v2 Oslo message queue Specify the Cinder v2 Oslo message queue. Optional
    Heat v2 Oslo message queue Specify the Heat v2 Oslo message queue. Optional
    Number of consumer instances Specify the number of consumer instances to create for each API queue type. Optional
    Access scope

    Enter text to provide a scope for the resources.

    Access scope can help map alerts to resources when resources in different scopes share the same parameters, such as matchTokens.

    		 Optional.
    Tip: You can define access scope for locations, project names, namespaces, etc.
    Generate debug support file
    Set the optional Generate debug support file parameter to 'True' in order to capture the output of the next scheduled job run as a file. This file will be stored with an observer's log files and can be used to debug observer issues, for example at the request of your designated Support team, or while using a test environment. For one-off jobs (that is, Load jobs), this parameter reverts to 'False' after the next completed run. To examine the output produced, you can load the generated debug file using the File Observer. The file is saved to the following locations:
    On-prem
    $ASM_HOME/logs/<obs>-observer/
    On OCP
    /var/log/itsm/<obs>-observer
    		 Optional
    Observer job description Enter additional information to describe the job. Optional
    Job schedule

    Specify when the job should run, and whether it should run at regular intervals.

    By default the job runs immediately, and only once.

    Optionally you can specify a future date and time for the job to run, and then set it to run at regular intervals after that.

    Optional. Transient (one-off) jobs only.

    If you set a job schedule, the run intervals must be at least 90 seconds apart, and if you set them at less than 15 minutes, a warning is displayed, as the frequency can impact system performance.
    SSL requirements: To acquire SSL certificates and build SSL truststores, use the relevant instructions in the following section: Configuring observer job security