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?

OpenStack-dev mailing list

Reply via email to