Open Stack

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

dmakogon at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140523/393d10d4/attachment-0001.html>