> > > > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
