Open Stack

ceilometer/objectstore/swift_middleware.py[1] counts the size of web
request and reponse bodies through the swift proxy server and publishes
metrics of the size of the request and response and that a request
happened at all.

There are (at least) two bug reports associated with this bit of code:

* avoid requirement on tarball for unit tests
   https://bugs.launchpad.net/ceilometer/+bug/1285388

* significant performance degradation when ceilometer middleware for
   swift proxy uses
   https://bugs.launchpad.net/ceilometer/+bug/1337761

On the first bug the goal is to remove the dependency on swift from
ceilometer. This is halfway done but there are barriers[2] with
regard to the apparently unique way that swift does logging and the
fact that InputProxy and split_path live in swift rather than some
communal location. The barriers may be surmountable but if other
things in the same context are changing, it might not be necessary.

On the second bug, while the majority of the performance cost is in
the call to rpc_server.cast(), achieving maximum performance would
probably come from doing the counts and notifications _not_ in
middlewhere. The final application in the WSGI stack will know the
size of requests and responses without needing to sometime recalculate.
May as well use that.

These two situations overlap in a few ways that suggest we could make
some improvements. I'm after input from both the swift crew and the
ceilometer crew to see if we can reach something that is good for the
long term rather than short term fixes to these bugs.

Some options appear to be:

* Move the middleware to swift or move the functionality to swift.

   In the process make the functionality drop generic notifications for
   storage.objects.incoming.bytes and storage.objects.outgoing.bytes
   that anyone can consume, including ceilometer.

   This could potentially address both bugs.

* Move or copy swift.common.utils.{InputProxy,split_path} to somewhere
   in oslo, but keep the middleware in ceilometer.

   This would require somebody sharing the info on how to properly
   participate in swift's logging setup without incorporating swift.

   This would fix the first bug without saying anything about the
   second.

* Carry on importing the swift tarball or otherwise depending on
   swift.

   Fixes neither bug, maintains status quo.

What are other options? Of those above which are best or most
realistic?

Personally I'm a fan of the first option: move the functionality into
swift and take it out of middleware. This gets the maximum win for
performance and future flexibility (of consumers).

[1]
https://github.com/openstack/ceilometer/blob/master/ceilometer/objectstore/swift_middleware.py

[2] https://review.openstack.org/#/c/110302/

-- 
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent