Open Stack

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 <jaypipes at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140922/a5cf0a4a/attachment.html>