ManageIQ and Openstack Events

This article describes how Events from OpenStack telemetry are used in ManageIQ cloud management tool. There are multiple telemetry technologies in OpenStack, but this article focuses on TripleO / RHOS distribution.


An OpenStack Event is a short mesage basically including timestamp, event-type and payload. The payload typically contains more detailed information about objects which the Event is related to (e.g. VM UUID for compute.instance.reboot event).

Purpose of capturing Events from OpenStack is to

  1. trigger refresh to keep OpenStack inventory in ManageIQ database up-to-date
  2. collect events for display provider Timelines feature
  3. allow Automate to process Events (trigger custom automation based on captured events).

OpenStack Events APIs

Historically (OSP6), the first solution was a direct connection from ManageIQ to RabbitMQ/AMQP message bus on OpenStack side. Later, Ceilometer project came to provide telemetry-related function to OpenStack environment via standard HTTP API listed in Keystone service list and using Keystone auth. After OSP10, Ceilometer broke up into smaller pieces including Panko for serving Events. API itself between Ceilometer Events and Panko stay nearly the same.

All three options should work with ManageIQ.

Events capture

ManageIQ process Openstack::[Cloud|Infra|Network|Storage]::EventCatcher is responsible for capturing events from OpenStack. It periodically (~20s) queries OpenStack for new events based on timestamp filter (greater than the last received Event timestamp).

Once OpenStack is added to ManageIQ as provider, Event monitor attempts to load all available events, by default including all historical Events too. That might take longer time, so :event_skip_history Settings option can skip all historical events and start with current timestamp.

Related source code for event monitors is

Events processing

Events are processed by Automate engine. ManageIQ-content repo contains OpenStack event types definition with actions which should be triggered. Most often usage is to trigger refresh.

Refresh code parses the Event and find the right objects to be refreshed. This is called Targeted Refresh and it avoid long lasting full refresh by calling only neccessary API calls.

Except the refresh, the Event should be visible in Timelines view on the provider.


Working Events monitor is a requirement for smooth ManageIQ OpenStack integration. Next article will focus on other OpenStack telemetry piece which are Metrics.

#manageiq #openstack