Ceilometer evolved from a simple meter gathering component to a lot of different component doing different things. The storage layer has been abstracted during Juno and Kilo and is going to be handled by Gnocchi. This spec proposes that the work continues so that the alarming subsystem of Ceilometer is split out as an autonomous component connected to the rest of Ceilometer and Gnocchi.
This should help with code review, maintenance, deployment, upgrade… as having several small service-oriented components to manage is going to be easier than a single monolithic project.
Currently, Ceilometer features can be grouped in different components, mainly:
These all 3 components are currently merged in one code base and repository, whereas they are different service talking to each other. This leads to a bit of spaghetti code and architecture when digging the project.
We want to improve project management, code review, upgrade, etc, by spliting the alarming subsystem out of Ceilometer main repository and having it living its own life in its own repository.
The new repository and project will be called either aodh.
Do nothing and continue growing the project until it collapses.
The main data model impact was storing alarms in a different database than the samples and events. This change already been implemented in Juno.
The alarming API should not change and continues to be contained in /v2/alarms. However, the ceilometer-api endpoint and daemons is going to be replace by a specific REST API daemon only implementing the alarming subsystem. This means a new Keystone endpoint will need to be created and registered.
We’ll also provide a documentation about how to support configuring a proxy that can route requests to the Ceilometer API endpoint or the new alarm API endpoint.
As stated above, this will require a new Keystone endpoint to manipulate alarms.
It’s easy to envision a better scalability if anything. It’ll be easier to scale the API endpoint for alarming only. Also, performances might be a little improved as the alarming codebase could be smaller.
The configuration file used by the alarming subsystem when it’ll be part of its own project/repository should be split out of ceilometer.conf. That means a new configuration file, but close to the current ceilometer.conf file, should be created.
Other than that, no option should be added or removed.
The daemon will remain the same and the API will be deployed in the same way – either with a (new) daemon either through the recommended WSGI interface.
The subsystem will be released independently than Ceilometer on its own schedule, like it’s already the case for Gnocchi and now other OpenStack projects. A coordinated release at the end of each cycle will happen too.
The new code repository hosting Ceilometer alarming will require a new core review team which will be composed of a copy of the current ceilometer-core reviewers.
This Ceilometer subproject will be able to be released on its own like the rest of the OpenStack projects/components.
Work items 4 can be removed if the project agrees to not having a deprecation period. Otherwise, core reviewer will have to be careful that the no code changes/fixes are merged into Ceilometer rather than the new repository.
The testing coverage should remain the same, using unit tests and functional tests with Tempest.
The documentation will have to be updated to include this new component in lieu of the current Ceilometer alarm.