Open Stack

On 09/24/2014 09:48 AM, Day, Phil wrote:
>>> I think we should aim to /always/ have 3 notifications using a
>>> pattern of
>>>
>>> try: ...notify start...
>>>
>>> ...do the work...
>>>
>>> ...notify end... except: ...notify abort...
>>
>> Precisely my viewpoint as well. Unless we standardize on the above,
>> our notifications are less than useful, since they will be open to
>> interpretation by the consumer as to what precisely they mean (and
>> the consumer will need to go looking into the source code to
>> determine when an event actually occurred...)
>>
>> Smells like a blueprint to me. Anyone have objections to me writing
>> one up for Kilo?
>>
>> Best, -jay
>>
> 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.

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