Open Stack

On Wed, Sep 24, 2014 at 9:48 AM, Day, Phil <philip.day at hp.com> 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.
>

+1 Following similar thinking, Keystone recently dropped a "pending"
notification that proceeded a single DB call, which was always followed by
either a success or failure notification.


>
> Phil
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140925/a235675c/attachment.html>