<br><br><div class="gmail_quote">On Wed, Jun 13, 2012 at 4:26 PM, Caitlin Bestler <span dir="ltr"><<a href="mailto:Caitlin.Bestler@nexenta.com" target="_blank">Caitlin.Bestler@nexenta.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Doug Hellmann wrote:<br>
<br>
</span><u></u><u></u></p>
<div><div class="im">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d">></span>There are a couple of other alternatives:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d">></span>1. We could move notification handling into its own daemon to get it out of the collector. This new daemon would still run on a central service, and would need to be set up to support load balancing
<span style="color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">></span>just as the collector is now. The similarities are why we left the two types of processing in the same process to begin with.<u></u><u></u></p>

</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d">></span>2. We could modify nova to include more details about an instance when it publishes a notification. This is the best solution from our perspective, and I would like to see all of the properties anyway,
<span style="color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">></span>but I don't know if there is a performance-related reason for leaving out some details.<u></u><u></u></p>

</div>
</div><div>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This problem is either simpler than the discussion implies, or there are constraints that are not being made explicit.<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">But to me the choice would be simple. If the data will typically be used by the receiving entity, it should be included in the notification.<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Asynchronously fetching the data from some form of persistent storage is making the system more complex. That complexity would only<br>

be justified if a) there was optional data that the receiver of the notification would frequently not bother to read, and the goal is to limit<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The bandwidth to the data that will *<b>probably</b>* be consumed, </span></p></div></div></div></div>
</blockquote><div><br></div><div>I was concerned about both, but I am convinced that the right solution is to include all of the details about the instance in the notification data generated by nova. I am going to work on that patch.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">or b) once this data is included the total data rate becomes erratic, so limiting<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The notification size allows the bulk data transfer to be smoothed out without slowing down the acceptance of other notifications.<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In either case, building a more complex system to make delivering bulk data deferrable implies that the deferred data is large. Why not<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Store it in a blob (i.e. in a Swift object), rather than in a database entry?<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</div>
</div>
</div>
</div>

</blockquote></div><br>