Open Stack

(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