Jump to: navigation, search

Meetings/Ceilometer/Liberty Virtual Mid-Cycle

Ceilometer will be having a virtual mid-cycle for Liberty.

It will be held throughout the day on 9 & 10 July and address the following topics. The schedule is being worked out and will eventually be available on this calendar


We will be attempting to use google hangouts for as our communication medium. If that doesn't work out we will fall back to Bluejeans. And that if that doesn't work out we will fall back to IRC.


More detail about individual topics at https://etherpad.openstack.org/p/ceilometer-liberty-midcycle-agenda



original etherpad

The main thrusts of the session were twofold:

  • Making sure that there is sufficient testing and experimentation to demonstrate that Gnocchi is sufficiently performant and feature complete that it is fit for purpose.
  • Doing the documentation and integration work to ensure that Gnocchi is visible to both the OpenStack community and other interested communities.


  • Gate job which tests dispatch from ceilometer to gnocchi sileht
  • A command line gnocchi client prad
  • Plan a summit design session on how to improve the resource definition parts of gnocchi. everyone
  • Work to attract more people outside OpenStack to Gnocchi jd
  • Optimise the dispatcher in ceilometer so that is fast, can track events for handling resource creation and can, if it proves better, do batching ilya
  • Improve the user/operator docs for installation and doing stuff with gnocchi so it is frictionless jd
  • Location the performance hockey stick gordc


original etherpad

We agreed on minimum sets of fields for samples and events:


  • id (implicit)
  • resource_id
  • timestamp (implicit)
  • meter_name
  • meter_type
  • meter_unit
  • volume


  • timestamp (implicit)
  • id (implicit)
  • type


Implementation of a declarative approach for notifications is ongoing. We will have one yaml file called meter.yaml for currently existing meters that originate from notifications.

Next steps:

  • Mark required fields in the yaml file
  • Create a separate file for external user defined meters
  • Cross-project activities
    • Check on the status of Nova's notification tidy-up work (ildikov)
    • Cooperate with Nova if possible

Long term future:

  • Consider splitting the meter.yaml file and store the parts in the emitter project's repo
    • We need to write up a Pro/Con list first for this approach

Alarm Split Out / Aodh

original etherpad

Not sure what the summary is for this. Someone else will need to fill this part in.

Collection Split

original etherpad

We were trying to decide what the shape of splitting of collection agents to their own repo should be, and what to name it. What we decided was to not do the split this cycle but to wait until M* to allow the Aodh split to settle in.

However the removal of transformers from the polling agents will continue:


Delete or Deprecate

orginal etherpad

We were trying to figure out whether it is better or worse to delete code that has been split out or to deprecate it over some period of time (one or two cylces). We did not reach a clear consensus but there was a general sense that pulling code out from under packagers would be a bad idea.

So the current plan seems to be that we will not delete the code out of Liberty but will out of M*. To ensure that this we will do the stuff in Tasks below.


  • Delete test/code for meters covered by new declarative meters prad
  • Find a resource to make a document telling operators the difference between ceilometer-alarm and aodh gordc
  • Send email to operators and dev list to people know what's up and fish, subtly, for freaking out. Get sense of whether L or M delete is more or less sane gordc

Event-Based Alarming

original etherpad

We agreed to use new evaluator for event base alarms, which will listen for notifications. All changes will be added into aodh repository. We also agreed to add event transformer and timeout event alarms.


  • Do it aodh r-mibu
  • Сhoose the optimal way for timeout alerting implementation (transformer/evaluator side) idegtiarov

v3 API and How to make and manage a roadmap

original etherpad

API v3 will most probably be a set of APIs offered by the different components like Aodh and Gnocchi. Mapping bbetween the functionality of the API v2 and Gnocchi's is most probably impossible. PI v2 will be maintained for 2 cycles from the point we deprecate it.


  • Proper documentation of changes and roadmap/plans
    • New APIs
    • Configuration/Upgrade info
  • Document current roadmap for Liberty (Done)

Integration Tests

We were discussing what variants should we choose for integration tests. There are several options: Tempest, Rally or in-tree tests. Each of these categories has it's pros and cons. It was decided to have some init tests for Rally and research plugin mechanism in Tempest. For Aodh it was decided not to test all storages, it's enough to choose only one and concentrate on Alarm functionality testing.


  • The following tests should be moved into a 'functional folder': all tests which start real backend or real services, gabbi tests. All other tests will kept in unit folder.
  • Research plugin mechanism in Tempest
  • Rally: we need some init tests at least. Benchmarking and Integration. Separate job in Jenkins will process the scenarios created in our tree
  • For performance tests: we made some tests, there should be scripts for them. Find it and think about reuse Ilya