Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/fuel/+spec/fuel-aodh-integration
Fuel has to deploy Aodh alarming in the environments with Ceilometer.
Aodh is the alarm engine of the Ceilometer project. This project has been founded based on the alarming services code of Ceilometer since Liberty. All alarm relative code has been deleted from the Ceilometer project in Mitaka. So, for the alarm supporting Aodh has to be deployed by Fuel. [1]
Aodh provides alarm functional on the Ceilometer database. The main idea of this proposal is deploy Aodh as a separate project with Ceilometer.
Aodh has 4 services which should be started:
Service aodh-api provides an access to alarms for the user. This service runs under HAProxy with mod_wsgi or eventlet. Endpoint for this service should be registered in keystone service catalog, because Ceilometer API uses this endpoint for proxying alarm related requests from Ceilometer client. It means that it’s better to install and run aodh-api before running ceilometer-api service. Service ‘aodh-api’ uses a Keystone for the authenticating requests. API described in [2].
Service aodh-evaluator evaluates alarms on a periodic basis. The default interval is 1 minute. This service runs as current ceilometer-alarm-evaluator service under the pacemaker with one active and other passive services. It caused by fact what coordination needed for the several instances of aodh-evaluator.
Service aodh-listener provides evaluating for the event alarms. It listens to the queue and evaluates alarms if event for this alarm is received. This service doesn’t need a coordination and can be started on every controller as service with respawn. This service uses an oslo.messaging listeners for the receiving messages from the queue.
Service aodh-notifier effects notification actions that is described in alarm for the state transition of individual alarm (to ok, alarm, insufficient data). This service doesn’t need a coordination and can be started on every controller as service with respawn. This service need a connection to the AMQP.
The default database for aodh is MySQL and connection url should be defined in configuration file. Binary aodh-dbsync running is required before the first Aodh services starting.
Fuel modular manifests for described services deployment should be created.
We need to make two minor modifications in the cluster creation wizard and on the Settings -> OpenStack services tab. On the both we should tell that Ceilometer and Aodh will be installed. In other respects it will be same as current Ceilometer installation.
It supports current business logic and doesn’t need any changes.
No changes in the data Nailgun data model.
No changes in Nailgun API.
No changes in the Fuel client.
None
Puppet manifests will perform next actions before Ceilometer deploying:
- install Aodh packages
- configure Aodh
- sync database
- configure Keystone endpoint for the aodh-api
- run aodh-evaluator under pacemaker
- start other Aodh services
None
There is no impact of master node upgrade. Upgrading existing cluster with Ceilometer to MOS 9.0 will include an alarm migration from the MongoDB Ceilometer db to MySQL Aodh database.
Script for this action is in progress in upstream part of Aodh.
None
None
API for the end users will be the same as current Ceilometer API. All alarm request will be redirected automatically to the Aodh API.
Aodh performance is the same as current performance level of Ceilometer alarm services.
Everything was already mentioned.
None
None
New services have a documentation space in Openstack wiki. [3] So, note about fact of Aodh installation should be added in Fuel docs associated with Ceilometer installations.
Packages for the AODH services and code should be prepared: * aodh-api * aodh-common * aodh-doc * aodh-evaluator * aodh-expirer * aodh-listener * aodh-notifier * python-aodh
Work items or tasks – break the feature up into the things that need to be done to implement it. Those parts might end up being done by different people, but we’re mostly trying to understand the timeline for implementation.
No additional dependencies