Open Stack

hi folks

it was great seeing/meeting all those who could make it to the Vancouver summit. i hope everyone had a productive summit and also enjoyed Vancouver (go Canucks!). for those who couldn't make it or for those interested, here are some of the items we talked about and will be tracking in the upcoming cycle.[1] (the following is a brain dump and does not reflect any prioritisation)

-- componentisation -- [2]
Ceilometer consists of several discrete services: polling, notification handling, storage, and alarming. for the most part, packaging is done to match these functionalities but the code itself is contained all in a single repo. this has lead to some confusion as to how Ceilometer can be used/deployed and a generic 'ceilometer' term to define any part of the functionality. the idea for separating the code is to: enable easier consumption for new developers, allow easier/precise classification of issues, to get a better sense of what parts of Ceilometer are more important so resources can be prioritised better, in addition to other potential wins. the first step will be to separate the alarming functionality and we will re-evaluate from there.

-- alarming on events -- [3]
in Kilo, we added a more complete functionality for capturing events in OpenStack. in Liberty, we aim to provide alarming functionality to events. the idea is again to start small and to enable immediate alarming when a change in status is detected and also when specific actions pass timing thresholds. from there, we will see how we can expand it's scope.

-- polling agent load -- [4]
a complaint regarding Ceilometer has been the load it places on the apis of services. while there are small workaround such as creating a dedicated api for just Ceilometer so that it does not affect general OpenStack processes, further enhancements are being looked at.

-- declarative meters -- [5]
when adding a meter to Ceilometer, you need to write code. the code is often just a process of copying existing meter, pasting code into a new section, and editing a variable or two. this is extremely inflexible and even more unnecessary. the new proposal is to define meters in a yaml file which defines what values of a notification become meters. this allows for better ease of use and the ability for users to easily define their own meters.

-- graceful pipeline reconfiguration -- [6]
for this item, the basic premise is to allow the modification of pipelines and have the agents update to accommodate new pipeline configuration without having to do a hard restart of service

-- gnocchi -- [7][8][9]
there's this thing called gnocchi. it's a new time-series driven storage backend.

-- documentation --
there's a lot of confusion as to how to use and deploy Ceilometer[10]. there was a talk to highlight some items but we'll be publishing a bit more help to enable operators.

-- other --
initial trial of oslo.versionobjects, in-tree functional testing, bugs, etc...


so there's the long summary. for those interested in helping out, feel free to reach out. for those with ideas we haven't discussed, feel free to reach out. as always irc:#openstack-ceilometer and [ceilometer].


[1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Ceilometer
[2] https://review.openstack.org/#/c/184307/
[3] https://review.openstack.org/#/c/172893/
[4] https://review.openstack.org/#/c/185084/
[5] https://review.openstack.org/#/c/178399/
[6] https://review.openstack.org/#/c/171826/
[7] https://julien.danjou.info/blog/2015/openstack-gnocchi-first-release
[8] www.slideshare.net/EoghanGlynn/rdo-hangout-on-gnocchi
[9] http://blog.sileht.net/autoscaling-with-heat-ceilometer-and-gnocchi.html
[10] www.openstack.org/summit/vancouver-2015/summit-videos/presentation/stabilizing-the-jenga-tower-scaling-out-ceilometer


cheers,
gord

** crosses fingers on formatting **