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
Contents
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.
- Google Hangout:
- BlueJeans(Fallback Option):
- To join the Meeting: https://bluejeans.com/112984718
Topics
- gnocchi production ready™
- Topic lead: gordc
- Topic etherpad: https://etherpad.openstack.org/p/gnocchi-production-ready
- Day two session? No replaced by a review what we've planned session.
- schematisation
- Topic lead: ildikov
- Topic etherpad: https://etherpad.openstack.org/p/ceilometer-schematization
- Day two session? Yes noon UTC
- alarm split
- Topic lead: jd
- Topic etherpad: https://etherpad.openstack.org/p/aodh-future
- Day two session? No
- collection split
- Topic lead: cdent
- Topic etherpad: https://etherpad.openstack.org/p/ceilometer-collection-split
- Day two session? No
- delete or deprecate
- Topic lead:
- Topic etherpad: https://etherpad.openstack.org/p/ceilometer-d-or-d
- Day two sesion? Maybe
- event-based alarming
- Topic lead: liusheng
- Topic etherpad: https://etherpad.openstack.org/p/event-based-alarming
- Day two session? No
- How to make and manage a roadmap (was: APIv3 (post split API))
- 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
- Topic lead: nadya
- 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
Summaries
Gnocchi
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
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
Implementations 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
Not sure what the summary is for this. Someone else will need to fill this part in.
Collection Split
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
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
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
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.