On 9/25/2014 11:09 AM, Day, Phil wrote:
Hi Jay,
So just to be clear, are you saying that we should generate 2
notification messages on Rabbit for every DB update? That feels
like a big overkill for me. If I follow that login then the current
state transition notifications should also be changed to "Starting to
update task state / finished updating task state" - which seems just
daft and confuisng logging with notifications.
Sandy's answer where start /end are used if there is a significant
amount of work between the two and/or the transaction spans multiple
hosts makes a lot more sense to me. Bracketing a single DB call
with two notification messages rather than just a single one on
success to show that something changed would seem to me to be much
more in keeping with the concept of notifying on key events.
I can see your point, Phil. But what about when the set of DB calls takes a
not-insignificant amount of time? Would the event be considered significant
then? If so, sending only the "I completed creating this thing" notification
message might mask the fact that the total amount of time spent creating
the thing was significant.
Sure, I think there's a judgment call to be made on a case by case basis on
this. In general thought I'd say it's tasks that do more than just update the
database that need to provide this kind of timing data. Simple object
creation / db table inserts don't really feel like they need to be individually
timed by pairs of messages - if there is value in providing the creation time
that could just be part of the payload of the single message, rather than
doubling up on messages.
That's why I think it's safer to always wrap tasks -- a series of actions that
*do* one or more things -- with start/end/abort context managers that send
the appropriate notification messages.
Some notifications are for events that aren't tasks, and I don't think those
need to follow start/end/abort semantics. Your example of an instance state
change is not a task, and therefore would not need a start/end/abort
notification manager. However, the user action of say, "Reboot this server"
*would* have a start/end/abort wrapper for the "REBOOT_SERVER" event.
In between the start and end notifications for this REBOOT_SERVER event,
there may indeed be multiple SERVER_STATE_CHANGED notification
messages sent, but those would not have start/end/abort wrappers around
them.
Make a bit more sense?
-jay
Sure - it sounds like we're agreed in principle then that not all operations
need start/end/abort messages, only those that are a series of operations.
So in that context the server group operations to me still look like they fall
into the first groups.
Phil
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Just for closure, we went with the single notification in the server
groups create/update/delete calls:
https://review.openstack.org/#/c/107954/
--
Thanks,
Matt Riedemann
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
