Open Stack

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

Phil