Refactor Notification

charlesw, I've I personally of with refactoring, the only point I have is integration with Ceilometer (http://docs.openstack.org/developer/ceilometer/measurements.html#key-value-store-magnetodb). ATM the first three types of notifications (lines 11-13) are processed by Ceilometer driver and we have to keep it. Eather update Celiometer integration or leave these events as is.
What do you think?

~isviridov

isviridov, thanks for the comments. I've renamed the event name to comply with Ceilometer doc. Currently the event names actually do not comply. I've changed them and updated the google doc. Will update the spec as well.

charlesw, I actually thought that after the refactoring we'd only have notifications in middleware and async-task-executor. This would indeed make the codebase cleaner. But as I can see now, you're plan to leave EVENT_TYPE_TABLE_CREATE_START, EVENT_TYPE_TABLE_CREATE_END, etc
where they are now, in storage manager. So we'll have three places where notifications are sent from (middleware, async executor and storage manager) instead of only two that we have now

~ikhudoshyn

ikhudoshyn, thanks for pointing it out. I decided to remove the _START events and rename the _END events to CRETAE_TABLE and DELETE_TABLE to comply with Ceilometer doc.

The events, however, will remain in storage manager's simple and async_simple implementations since async_task_executor is only one of the implementations configurable. Only two places will send such events though: middleware for request events, simple_impl/async_simple_impl/queued_impl for task events.

Gerrit topic: https://review.openstack.org/#q,topic:bp/request-metrics,n,z

Addressed by: https://review.openstack.org/143115
    Add real time request metrics and refactor notification

Gerrit topic: https://review.openstack.org/#q,topic:bp/refactor-notification,n,z