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


OpenStack-dev mailing list

Reply via email to