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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
