Open Stack

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 at 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