confirmed On 04/02/2014 04:47 PM, Gordon Chung wrote: > 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 > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
