Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
It has been discussed to merge the ceilometer hardware agent into the central agent during the last weeks' IRC meetings. But there are still some issues in the current central agent we need to address:
- How to horizontally scale out the central agent? Currently, there is only one central agent allowed in the ceilometer deployment, otherwise there will be much duplication of the metering/monitoring samples. We need to figure out how to deploy several central agents without such duplication.
We may possibly follow the current alarm partition way, i.e. one dynamically elected master central agent will distribute the resources among all the central agents for them to poll.
One thing to be noticed is that unlike the alarm service which have only 1 type of resource - alarms, central agent will have different types of resources for different pollsters, i.e. glance resources, swift resources, hardware resources, etc. The distribution process must take that into account to avoid distribute the resources to other central agent which is not configured to have the relevant pollsters for that type.
- Do we want to allow the admin to manually configure what resources to be polled in the pipeline configuration file? Besides getting all the available resources from a 3rd party API endpoint, i.e. glance/swift/neutron API, I think it'd better also allow the admin to manually configure the resources in the pipeline file, by adding a new 'resources' item into the pipeline file, just like what the hardware agent does now. The gives the admin much more flexibility.
