Open Stack

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