Open Stack

hi,

i'd like to announce my candidacy for PTL of Ceilometer.

as a little background, i've been a contributor to OpenStack for the past 
year and a half and have been primarily focused on Ceilometer for the past 
two cycles where i've been a core contributor. i contribute regularly to 
the project with code [1] and am one of the top reviewers [2]. i am also a 
developer at IBM where i work on the IBM software standards team, building 
standards such as the Cloud Audit Data Federation Working Group (CADF) 
specification.

there's a great deal to be discussed at the upcoming summit and i'm sure 
Ceilometers' contributors and deployers have a lot of ideas. in addition 
to those, i think some key items to focus on are:

- improving collector performance in Ceilometer. this has been a major 
item in Ceilometer recently as we tried to expand our integration tests in 
tempest and have found there are inefficiencies in how Ceilometer is 
collecting data. Ceilometer should be a lightweight service, capable of 
processing heavy load and we need to ensure it can handle this. i'd like 
to revisit our models (to ensure our model match what operators require) 
and build our backends around this so they are highly tuned to writes and 
reads for these use cases.
- improving polling agents. the compute agent currently creates a heavy 
load on compute-api[3] and the central agent has it's own performance and 
HA issues... it's something we should really considering looking at.
- continue to expand tempest testing in ceilometer. the tempest tests have 
been helpful in identifying gaps/performance issues and will help later in 
identifying regression.
- review how we log in Ceilometer. we have a very repetitive framework 
design so our logs can be extremely overwhelming or extremely sparse. 

some other items to track (depending on resource) are:

- enhancing event support. there is a framework for events in Ceilometer 
but there is work to be done to make it a true monitoring tool. we have a 
few blueprints existing in Ceilometer that should help.
- re-evaluating the alarming service. we currently require two services to 
run for alarms, a notifier and an evaluator which also depends on the 
ceilometerclient. there is an interesting bp to move some alarm logic to 
the pipeline and i think we should take a look at it to see if it provides 
a cleaner, leaner solution.[4]. if not, we should work on documenting our 
current implementation.

[1] 
https://review.openstack.org/#/q/owner:chungg+status:merged+project:openstack/ceilometer,n,z
[2] http://russellbryant.net/openstack-stats/ceilometer-reviewers-365.txt
[3] 
http://openstack-in-production.blogspot.ca/2014/03/cern-cloud-architecture-update-for.html
[4] https://blueprints.launchpad.net/ceilometer/+spec/alarm-pipelines

cheers,
gordon chung
openstack, ibm software standards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140402/f39f3ea6/attachment.html>