<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>For instance, an instance migration can take a while since we need to</div><div>copy many gigabytes of disks to another host. If we want to do a</div><div>software upgrade, we either need to wait a long time for the migration</div><div>to finish, or we need to restart the service and then restart the</div><div>processing of the message.</div></div></div></span></blockquote><div><span style="font-size: 12px;">You wait a long time period. If you wait a long time and it fails, you're restarting. Having it do so automatically on the consumer-side isn't necessarily a good thing.</span> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>If all software gets restarted, then persistence is important.</div></div></div></span></blockquote><div><span style="font-size: 12px;">Again, I see an argument in having callers have limited persistence, but not consumers.</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div></div><blockquote type="cite"><div><div>All calls have a timeout (TTL). The ZeroMQ driver also implements a TTL</div><div>on the casts, and I'm quite sure we should support this in Kombu/Qpid</div><div>as well to avoid a thundering-herd.</div></div></blockquote><div><br></div><div>What thundering herd problems exist in Openstack?</div></div></div></span></blockquote><div><br></div><div>Say we have one api service, one scheduler.  If the scheduler fails, API requests to create an instance will pile up, until the scheduler returns. The returning scheduler will get all of those instance creation requests and will launch those instances. (This would also be applicable for messages between the scheduler and a compute service)</div><div><br></div><div><span style="font-size: 12px;">The end-user will see the run-instance command as potentially failing and may attempt to launch again. The queue will hold all of these requests and they will all get processed when the scheduler returns.</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">This is especially problematic with auto-scaling. How well will Rightscale or Enstratus run against a system that takes hours and hours to launch instances?  They'll just retry and retry. You don't want these to just queue up.</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div>I do know there are problems with queuing combined with timeouts. It</div><div>makes less sense to process a get_nw_info request if the requestor has</div><div>already timed out and will ignore the response. Is that what you're</div><div>referring to with TTLs?</div><div></div></div></div></span></blockquote><div><br></div><div>That is important too, in the case of calls, but not all that important.  I'm not so concerned about machines sending useless replies, we can ignore them.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div></div></div></div></span></blockquote><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>Idempotent actions want persistence so it will actually complete the</div><div>action requested in the message. For instance, if nova-compute is</div><div>stopped in the middle of an instance-create, we want to actually finish</div><div>the create after the process is restarted.<br></div><div></div></div></div></span></blockquote><div>Only if it hasn't timed out. Otherwise, you'd only asking for a thundering herd.</div><div><br></div><div><span style="font-size: 12px;">What has happened on the caller side? Has it timed out and given the user an error?  What manager methods (rpc methods) that call RPC, how deep does that stack go?</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Perhaps it is better that if nova-compute is stopped in the middle of an instance-create that it can *cleanup* on a restore, rather than attempting to continue an arguably pointless and potentially dangerous path of actually creating that instance?</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div>There is no process waiting for a return value, but we certainly would</div><div>like for the message to be persisted so we can restart it.</div><div><br></div></div></div></span></blockquote><div><span style="font-size: 12px;">I'm not sure about that.</span></div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div></div><blockquote type="cite"><div><div>Anyway, in the ZeroMQ driver, we could have a local queue to track</div><div>casts and remove them when the send() coroutine completes.  This would</div><div>provide restart protection for casts. </div></div></blockquote><div><br></div><div>Assuming the requesting process remains running the entire time?</div></div></div></span></blockquote><div><span style="font-size: 12px;">I meant ONLY persisting in the requesting process. If the requesting process fails while before that message is consumed, the requesting process can attempt to resubmit that message for consumption upon relaunch.  The requesting process would track the amount of time waiting for the message to be consumed and would subtract that time from the remaining timeout.</span>
                </div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Regards,</span></div><div><span style="font-size: 12px;">Eric Windisch</span></div>