openstack/election
Code Issues Proposed changes

Ceilometer PTL candidacy - Gordon Chung

Browse Source 
Change-Id: Id6abe8e0cf773247b51462a5796da3a54a0c13a6
This commit is contained in:
gordon chung 2015-09-15 10:53:09 -04:00
parent d4364047d6
commit 1df460979c
1 changed files with 44 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
candidates/mitaka/Ceilometer/gordon_chung.txt Normal file
View File

@ -0,0 +1,44 @@
hi folks,
less than six months ago, i decided to run for PTL of Ceilometer where my main
goal was to support the community of contributors that exists within OpenStack
with interests in telemetry[1]. it is under that tenet which i will run again
for team lead of Ceilometer. as mentioned previously, we have a diverse set of
contributors from across the globe working on various aspects of metering and
monitoring and it is my goal to ensure nothing slows them down
(myself included).
that said, as we look forward to Mitaka, i hope to follow along the path of
stability, simplicity and usability. some items i'd like to target are:
- rolling upgrades - having a fluid upgrade path for operators is critical to
providing a highly available cloud environment for their users. i would like
to have a viable solution in Ceilometer that can provide this functionality
with zero/minimal performance degradation.
- building up events - we started work on adding inline event alarming in Aodh
during Liberty, this is something i'd like to improve upon by adding multiple
worker support and broader alarming evaluations. also, a common use case for
events is to analyse the data for BI. while we allow the ability to query and
alarm on events. one useful tool would be the ability to run statistics on
events such as the number of instances launched.
- optimising collection - we improved ease of use by adding declarative
notification support in Liberty. it'd be great if this work could be adopted by
projects producing metrics. additionally, we currently have a extremely tight
coupling between resource metadata and measurement data. i'd like to evaluate
how to loosen this so our data collection and storage is more flexible.
- continuing the refactoring - removing deprecated/redundant functionality; it
was nice deprecating/deleting stuff, let's keep doing it (within reason)! one
possible target would be splitting storage/api, while starting the initial
deprecation of v2 metering api.
- functional and integration testing - we now have integration and functional
test living within our repositories. this should allow us to develop testing
easier so it'd be good to broaden the coverage.
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/060536.html
cheers,