Integration is provided via a plugin. There are multiple configuration settings required for proper indexing and incremental updates. Some of the settings are specified in Searchlight configuration files. Others are provided in other service configuration files.
Searchlight resource configuration options are shown below with their configuration file and default values.
See Searchlight Plugin Documentation for common options with their default values, general configuration information, and an example complete configuration.
Note
Unless you are changing to a non-default value, you do not need to specify any of the following configuration options.
[service_credentials:nova]
compute_api_version = 2.1
Note
Nova adds/removes fields using microversion mechanism, check https://docs.openstack.org/nova/latest/api_microversion_history.html for detailed Nova microversion history.
[resource_plugin:os_nova_server]
enabled = true
resource_group_name = searchlight
notifications_topics_exchanges = versioned_notifications,nova
use_versioned_notifications = true
This plugin represents each of the Nova compute nodes.
[resource_plugin:os_nova_hypervisor]
enabled = true
resource_group_name = sl_without_notification
Note
There are no notifications from the compute nodes (“hypervisors”) from nova yet, so we recommend putting it in its own resource group and scheduling a cron job to periodically re-sync. This will create a very low overhead way to keep the index up to date. The index latency will be dependent on how often you re-sync the data.
[resource_plugin:os_nova_flavor]
enabled = true
resource_group_name = searchlight
notifications_topics_exchanges = versioned_notifications,nova
Note
The notifications topic for flavors is versioned_notifications, so we need to config notifications_topics_exchanges with value ‘versioned_notifications,nova’ in order to get the related versioned notifications from nova.
[resource_plugin:os_nova_servergroup]
enabled = true
resource_group_name = searchlight
Note
The return value of os-server-groups API from nova doesn’t contain project and user information before nova API microversion v2.13, thus the index cannot been searched by particular project.
The nova services must be configured properly to work with searchlight.
Notifications must be configured properly for searchlight to process incremental updates. Enable notifications using the following:
[oslo_messaging_notifications]
driver = messagingv2
[notifications]
notify_on_state_change = vm_and_task_state
# notification_format = versioned
Note
Restart Nova API and Nova scheduler (n-api, n-sch) after making changes. See Notifications for more information on notification topics.
The default setting for notification_format is ‘both’ which sends both versioned and unversioned notifications. Searchlight uses ‘use_versioned_notifications’ to decide which to use.
The settings above may be automatically configured by stack.sh
by adding them to the following post config section in devstack.
Just place the following in local.conf and copy the above settings
underneath it.:
[[post-config|$NOVA_CONF]]
[DEFAULT]
Since changes to Neutron can affect Nova instances you may optionally turn on notifications for Neutron. If you do not, networking changes will only be picked up by Searchlight when notifications are received from Nova.
Notifications must be configured properly for searchlight to process incremental updates. Enable notifications using the following:
[oslo_messaging_notifications]
driver = messagingv2
Note
Restart the Neutron api service (q-svc) after making changes. See Notifications for more information on notification topics.
The settings above may be automatically configured by stack.sh
by adding them to the following post config section in devstack.
Just place the following in local.conf and copy the above settings
underneath it.:
[[post-config|$NEUTRON_CONF]]
[DEFAULT]
In order to reduce the impact on the nova API, changes have been made to the
way notifications are processed. Currently searchlight has to retrieve nova
server information from nova because the notifications alone are missing
several pieces of information. Prior to Newton this meant up to 7 API requests
during a server boot. During Newton this was changed. There will now be one
initial nova request prior to the scheduler, one when the
instance.create.start
notification is received, one when networking is
established and one after the instance has booted and run any init scripts.
Other notifications during boot will update only the server status.
Notifications must be configured properly for searchlight to process incremental updates. Searchlight must use its own topic. Use the following:
notification_driver = messaging
notification_topics = searchlight_indexer
Additional properties can be similarly protected with the admin_only_fields under each plugin’s configuration section. Glob-like patterns are supported. For instance:
[resource_plugin:os_nova_server]
admin_only_fields=OS-EXT-STS:vm_state
See: ADMIN_ONLY_FIELDS in: * searchlight/elasticsearch/plugins/nova/servers.py
All OS-EXT-SRV-ATTR:.* properties are filtered out from search results for non-admin users. This is not a configuration option in this release. To change this or filter out additional properties, you must change the plugin code to add additional properties.
See: ADMIN_ONLY_PROPERTIES in searchlight/elasticsearch/plugins/nova/servers.py
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.