Jump to: navigation, search

Difference between revisions of "Meetings/Ceilometer/Liberty Virtual Mid-Cycle"

(Schematisation)
(Schematisation)
Line 94: Line 94:
 
* type
 
* type
  
 +
=== Tasks ===
  
Implementations of a [https://review.openstack.org/#/c/197633/ declarative approach] for notifications is ongoing. We will have one yaml file called meter.yaml for currently existing meters that originate from notifications.
+
Implementation of a [https://review.openstack.org/#/c/197633/ 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:
 
Next steps:

Revision as of 15:49, 12 July 2015

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

Media

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.

Topics

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

Summaries

Gnocchi

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.

Tasks

  • 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

Schematisation

original etherpad

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

MINIMUM SET FOR SAMPLE

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


MINIMUM SET FOR EVENT

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

Tasks

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:

Tasks

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.

Tasks

  • 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

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

Tasks

  • Do it aodh [owner]

v3 API and How to make and manage a roadmap

original etherpad

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

Tasks

Integration Tests

[original etherpad https://etherpad.openstack.org/p/ceilometer-integration-tests]

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