Hi Jay, There was actually a discussion about file a blueprint for object notification http://markmail.org/message/ztehzx2wc6dacnk2
But for patch https://review.openstack.org/#/c/107954/ , I'd like we keep it as it is now to resolve the requirement of server group notifications for 3rd party client. Thanks. 2014-09-22 22:41 GMT+08:00 Jay Pipes <jaypi...@gmail.com>: > On 09/22/2014 07:24 AM, Daniel P. Berrange wrote: > >> On Mon, Sep 22, 2014 at 11:03:02AM +0000, Day, Phil wrote: >> >>> Hi Folks, >>> >>> I'd like to get some opinions on the use of pairs of notification >>> messages for simple events. I get that for complex operations on >>> an instance (create, rebuild, etc) a start and end message are useful >>> to help instrument progress and how long the operations took. However >>> we also use this pattern for things like aggregate creation, which is >>> just a single DB operation - and it strikes me as kind of overkill and >>> probably not all that useful to any external system compared to a >>> single event ".create" event after the DB operation. >>> >> >> A start + end pair is not solely useful for timing, but also potentially >> detecting if it completed successfully. eg if you receive an end event >> notification you know it has completed. That said, if this is a use case >> we want to target, then ideally we'd have a third notification for this >> failure case, so consumers don't have to wait & timeout to detect error. >> >> There is a change up for review to add notifications for service groups >>> which is following this pattern (https://review.openstack.org/ >>> #/c/107954/) >>> - the author isn't doing anything wrong in that there just following >>> that >>> pattern, but it made me wonder if we shouldn't have some better guidance >>> on when to use a single notification rather that a .start/.end pair. >>> >>> Does anyone else have thoughts on this , or know of external systems that >>> would break if we restricted .start and .end usage to long-lived instance >>> operations ? >>> >> >> 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 > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Thanks, Jay
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
