meter aodh
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceilometer |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
taken from https:/
=======
Support Alarm Metering Data
=======
https:/
https:/
Problem description
===================
As a cloud vendor, I want to telemeter alarm resources, so I can bill
for such resources, but now, Ceilometer doesn't collect such metering data,
the only way we have is providing a very limited quota to every project.
This situation needs to be improved.
Proposed change
===============
For each polling cycle, ceilometer polling agent will call Aodh API to get
alarms usage for each project, then record as samples to back end, so billing
service can retrieve that data and charge on it.
Aodh will provide an API:
/v2/
If caller is non admin, then it will only return its own usage data.
If caller is admin and no project_id is specified, then will return a list of
all projects, each element is an usage data for a project.
If caller is admin and project_id is specified, only that project's usage data
will be returned.
the response is like this:
.. code-block:: json
[
{
'ok': 998,
}
]
Group by user_id will not be supported, we charge on project, not on individual
user.
When user creates an alarm, updates it or deletes it, aodh-api will send a
notification to AMQP, to notify Ceilometer that there is an event occurs.
The notification event_type will be:
* alarm.create.end (no start because we only write database)
* alarm.update.end (ditto)
* alarm.delete.end (ditto)
the payload will be consistent to the alarm API model, such as:
.. code-block:: json
{
"alarm_id": "aa0541eb-
"enabled": true,
"rule": {
},
"name": "I wish you have a happy life",
"severity": "low",
"state": "insufficient data",
"type": "event",
"user_id": "c417eb1ad2534d
}
Ceilometer can decide what to do for such notification, store it to event
backend and allow elasticsearch do something usefull, or drop it, whatever.
And notifications sent by aodh-evaluator and aodh-listener will be ignored
because we only want to audit user's operations.
The notification can be shutdown by configuration, just like other services
do.
Alternatives
------------
Lie down there and wait for complaint.
Data model impact
-----------------
None
REST API impact
---------------
Aodh will have a new API /v2/usage/
Security impact
---------------
None
Pipeline impact
---------------
None
Other end user impact
-------
None
Performance/
-------
None
Other deployer impact
-------
None
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
<zqfan>
Other contributors:
<None>
Ongoing maintainer:
<zqfan>
Work Items
----------
* Aodh provide the usage API
* Aodh send notification when API does CUD on alarm
* Ceilometer pollster for alarm count
* Ceilometer event for alarm notification
Future lifecycle
================
None
Dependencies
============
None
Testing
=======
* unit test for source code
* gabbi test for Aodh new API
Documentation Impact
=======
Will along with the code.
References
==========
None