Good day, Trove community.
I would like to start thread related to Trove notification framework. Notification design was defined as: “Trove will emit events for resources as they are manipulated. These events can be used to meter the service and possibly used to calculate bills.” Actual reason of this mail is to start a discussion related to re-implementing/refactoring of notifications. For now notifications are hard-pinned to nova provisioning. What kind of issues/problem do notifications have? Let's first take a look at how they are implemented. [1]<https://wiki.openstack.org/wiki/Trove/trove-notifications>– this is how notifications design was defined and approved. [2]<https://github.com/openstack/trove/blob/master/trove/taskmanager/models.py#L73-L133>– this is how notifications are being implemented. How notifications should look like [5] <https://wiki.openstack.org/wiki/Trove/trove-notifications-v2> . First of all, there are a lot issues with [2]<https://github.com/openstack/trove/blob/master/trove/taskmanager/models.py#L73-L133>: - pinning notifications to nova client – it's wrong way, because Trove is going to support heat for resource management<https://blueprints.launchpad.net/trove/+spec/resource-manager-interface> ; - availability zone – should be only used at “trove.instance.create” notification only, no need to use it each time “trove.instance.modify_*” happens (* - flavor, volume); - instance_size – this payload attribute referring to an amount of RAM defined by flavor; - instance_type – this payload attribute referring to flavor name, which seems odd; - instance_type_id – same thing, payload attribute referring to flavor id, which seems odd; - nova_instance_id – to be more generic, we should refuse from using specific names; - state_description and state – same referring to instance service status, actual duplication; - nova_volume_id – same as for nova_instance_id, should be more generic, since instance can have cinder volume that has nothing common with nova at all. We need to have more generic, more flexible notifications, that can be used with any provisioning engine, no matter what it actually is (nova/heat) How do we can re-write notifications taking into account described issues? 1. We need to re-write send_usage_event<https://github.com/openstack/trove/blob/master/trove/taskmanager/models.py#L88>method. 2. It should not ask nova for flavor, server and AZ, because it's redundant. So, the beginning of the method should look like [3]<https://gist.github.com/denismakogon/9c2d802e2a61eb6164d2> . 3. Payload should be re-written. It should have the following form [4]<https://gist.github.com/denismakogon/c4a784d364f0af0fc543> . What the actual value-add of this refactoring? Notifications would be reusable for any kinds of actions (create, delete, resizes), no matter what kind of the provisioning engine was used. Next steps after suggested refactoring? Next steps will cover required notifications that were described as part of the ceilometer integration.<https://blueprints.launchpad.net/trove/+spec/ceilometer-integration> Best regards, Denis Makogon www.mirantis.com dmako...@mirantis.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev