45 lines
2.2 KiB
Plaintext
45 lines
2.2 KiB
Plaintext
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,
|
|
|