Jump to: navigation, search

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

m
 
(26 intermediate revisions by 7 users not shown)
Line 15: Line 15:
  
 
* gnocchi production ready™
 
* gnocchi production ready™
** Topic lead: jd (has volunteered but admits that someone else might be a better choice, maybe prad or gordc?)
+
** Topic lead: gordc
 
** Topic etherpad: https://etherpad.openstack.org/p/gnocchi-production-ready
 
** Topic etherpad: https://etherpad.openstack.org/p/gnocchi-production-ready
 +
** Day two session? '''No''' replaced by a review what we've planned session.
 
* schematisation
 
* schematisation
 
** Topic lead: ildikov
 
** Topic lead: ildikov
** Topic etherpad:
+
** Topic etherpad: https://etherpad.openstack.org/p/ceilometer-schematization
 +
** Day two session? '''Yes''' noon UTC
 
* alarm split
 
* alarm split
 
** Topic lead: jd
 
** Topic lead: jd
 
** Topic etherpad: https://etherpad.openstack.org/p/aodh-future
 
** Topic etherpad: https://etherpad.openstack.org/p/aodh-future
 +
** Day two session? '''No'''
 
* collection split
 
* collection split
 
** Topic lead: cdent
 
** Topic lead: cdent
 
** Topic etherpad: https://etherpad.openstack.org/p/ceilometer-collection-split
 
** Topic etherpad: https://etherpad.openstack.org/p/ceilometer-collection-split
 +
** Day two session? '''No'''
 
* delete or deprecate
 
* delete or deprecate
 
** Topic lead:
 
** Topic lead:
 
** Topic etherpad: https://etherpad.openstack.org/p/ceilometer-d-or-d
 
** Topic etherpad: https://etherpad.openstack.org/p/ceilometer-d-or-d
 +
** Day two sesion? '''Maybe'''
 
* event-based alarming
 
* event-based alarming
 
** Topic lead: liusheng
 
** Topic lead: liusheng
 
** Topic etherpad: https://etherpad.openstack.org/p/event-based-alarming
 
** Topic etherpad: https://etherpad.openstack.org/p/event-based-alarming
* APIv3 (post split API)
+
** Day two session? '''No'''
** Topic lead:
+
* How to make and manage a roadmap (was: APIv3 (post split API))
** Topic etherpad:
+
** ''For the second day the topic has changed to reflect where discussion ended up on the first day.''
 +
** Topic lead: ildikov
 +
** Topic etherpad: https://etherpad.openstack.org/p/ceilometer-apiv3
 +
** Day two session? '''Yes''' 11am UTC
 
* in tree functional testing
 
* in tree functional testing
 
** Topic lead: nadya
 
** Topic lead: nadya
 
** Topic etherpad: https://etherpad.openstack.org/p/ceilometer-integration-tests
 
** Topic etherpad: https://etherpad.openstack.org/p/ceilometer-integration-tests
 +
** absent: gordc
 +
** Day two session? '''No'''
  
 
More detail about individual topics at https://etherpad.openstack.org/p/ceilometer-liberty-midcycle-agenda
 
More detail about individual topics at https://etherpad.openstack.org/p/ceilometer-liberty-midcycle-agenda
 +
 +
= Summaries =
 +
 +
 +
== Gnocchi ==
 +
 +
[https://etherpad.openstack.org/p/gnocchi-production-ready 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 ==
 +
 +
[https://etherpad.openstack.org/p/ceilometer-schematization 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 [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:
 +
* 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 ==
 +
 +
[https://etherpad.openstack.org/p/aodh-future original etherpad]
 +
 +
'''Not sure what the summary is for this. Someone else will need to fill this
 +
part in.'''
 +
 +
== Collection Split ==
 +
 +
[https://etherpad.openstack.org/p/ceilometer-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 ===
 +
 +
* Push split to post liberty
 +
* Carry on with removing transformations from polling agents ([review 198865 https://review.openstack.org/#/c/198865/])
 +
* Implement multi-queue handling in notification agents ([review 199331 https://review.openstack.org/#/c/199331/])
 +
 +
== Delete or Deprecate ==
 +
 +
[https://etherpad.openstack.org/p/ceilometer-d-or-d 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 ==
 +
 +
[https://etherpad.openstack.org/p/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.
 +
 +
=== Tasks ===
 +
 +
* 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 ==
 +
 +
[https://etherpad.openstack.org/p/ceilometer-apiv3 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.
 +
 +
=== Tasks ===
 +
* Proper documentation of changes and roadmap/plans
 +
** New APIs
 +
** Configuration/Upgrade info
 +
* Document current [https://wiki.openstack.org/wiki/Ceilometer 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.
 +
 +
=== Tasks ===
 +
 +
* 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''

Latest revision as of 15:53, 13 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

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.

Tasks

  • 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.

Tasks

  • 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.

Tasks

  • 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