Meeting in portland for the Havanah version of OpenStack.
Ceilometer Topics only please.
View the Meeting Home Page
- Starts:
- 09:00 UTC on Monday, 2013-04-15
- Ends:
- 18:00 UTC on Thursday, 2013-04-18
Meeting drivers
Each meeting has a person, or team, responsible for deciding which items are accepted for the agenda. This team is called the "meeting driver" and for Havana OpenStack Summit - Ceilometer they are:
You should contact the meeting driver if you have any additional questions about the structure or agenda of the meeting.
Blueprints
Latest 5 additions to the meeting agenda
|
Time series data manipulation in nosql stores
for Ceilometer
Ceilometer currently supports multiple storage drivers (mongodb, sqlalchemy, hbase) behind a well-defined abstraction.
The purpose of this blueprint is to investigate how well suited the existing nosql stores are to the efficient manipulation of time-series data.
The questions to be decided would include:
* whet...
|
|
|
Logical combination of alarm states
for Ceilometer
A mechanism to combine the states of multiple basic alarms into overarching meta-alarms could be useful in reducing noise from detailed monitoring.
We would need to determine:
* whether the meta-alarm threshold evaluation should be based on notification from basic alarms, or on re-evaluation of the underlying cond...
|
|
|
By default, the metrics gathering underlying ceilometer alarming can share the same infrastructure as the metering functionality.
However in realistic deployments, we envisage that operators may want to reflect differing requirements by separating off the transport conduit and storage elements.
Also the metering d...
|
|
|
Alarm API
for Ceilometer
We need to tie down the requirements for managing the state and history of alarms, for example providing:
* an API to allow users define and modify alarm rules
* an API to query current alarm state and modify this state for testing purposes
* a period for which alarm history is retained and is accessible to th...
|
|
|
Distributed & scalable threshold rule evaluation for alarms
for Ceilometer
A simple method of detecting threshold breaches for alarms is to do so directly "in-stream" as the metric datapoints are ingested. However this approach is overly restrictive when it comes to wide dimension metrics, where a datapoint from a single source is insufficient to perform the threshold evaluation. The in-st...
|
There are a total of 12 specifications on the meeting agenda. There are 9 specifications proposed which the organisers will review. You can view the full current agenda here.
