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