[openstack-dev] [ceilometer] PTL candidacy
chungg at ca.ibm.com
Wed Apr 2 20:47:24 UTC 2014
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  and am one of the top reviewers . 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)
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 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
- 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.. if not, we should work on documenting our
openstack, ibm software standards
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev