(This is tangentially, because of config handling, related to the other thread on ceilometermiddleware: http://lists.openstack.org/pipermail/openstack-dev/2015-June/067642.html )
tl;dr: Where and how should ceilometermiddleware be handled in devstack? I'm in the process of creating a devstack plugin for ceilometer and eventually removing ceilometer from the default devstack stack. This affords a nice opportunity for doing a bit of housecleaning and refactoring. One of the things I've noticed is that lib/ceilometer hosts an 'install_ceilometermiddleware' function which is used by stack.sh in the section where the swift service is being installed. lib/ceilometer itself, and ceilometer in general, does not use this function. This is because though ceilometermiddleware has ceilometer in its name as an artifact of history, it is not a ceilometer specific tool. It simply generates pycadf-based notifications about requests and responses on the swift proxy[1]. The actual use and configuration of ceilometermiddleware is managed in the lib/swift file. However it is guarded by 'is_service_enabled ceilometer' and the filter is named 'ceilometer'. This is perhaps a bit bizarre and confusing because anything that is configured to do so might like to consume these notifications, not just ceilometer. There are some questions that arise from these explorations: * What code should be calling and hosting install_ceilometermiddleware? Since it is lib/swift that is using it, there makes some sense? Especially since it already has a relatively long block of configuration instruction. * Should the filter factory have a different name or should we just carry on with what we have because it ain't broke? I have no opinion on this one. * Should the 'is_service_enabled ceilometer' guard go away and be replaced by some way of testing for or indicating "We want ceilometermiddleware"? I think we want the latter. If we don't we will be misrepresenting the way the middleware can work. But I'm not sure on the best way to make it so. * If we change the conditions on which the middleware will run, what needs to happen to ensure there is some measure (in the ceilometermiddleware project) of gating on swift? This is fairly opaque. Thanks for input. [1] Note that this is the future of all the data production tools currently under the ceilometer umbrella. The goal is to make them sufficiently generic to be used by themselves. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
