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


OpenStack-dev mailing list

Reply via email to