<div dir="ltr">Clint, Morgan, <div><br></div><div>I totally agree that the pub/sub model is better approach. </div><div><br></div><div>However, there are 2 great things about polling:</div><div>1) it's simpler to use than pub/sub (especially in shell)</div><div>2) it has really simple implementation & we can get this in OpenStack in few days/weeks</div><div><br></div><div>What about just supporting both approaches? </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 4, 2015 at 9:33 AM, Morgan Fainberg <span dir="ltr"><<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></span> wrote:<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"><p dir="ltr"><br>
On Nov 3, 2015 4:29 PM, "Clint Byrum" <<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>> wrote:<br>
><br>
> Excerpts from Boris Pavlovic's message of 2015-11-03 14:20:10 -0800:<br>
> > Hi stackers,<br>
> ><br>
> > Usually such projects like Heat, Tempest, Rally, Scalar, and other tool<br>
> > that works with OpenStack are working with resources (e.g. VM, Volumes,<br>
> > Images, ..) in the next way:<br>
> ><br>
> > >>> resource = api.resouce_do_some_stuff()<br>
> > >>> while api.resource_get(resource["uuid"]) != expected_status<br>
> > >>>    sleep(a_bit)<br>
> ><br>
> > For each async operation they are polling and call many times<br>
> > resource_get() which creates significant load on API and DB layers due the<br>
> > nature of this request. (Usually getting full information about resources<br>
> > produces SQL requests that contains multiple JOINs, e,g for nova vm it's 6<br>
> > joins).<br>
> ><br>
> > What if we add new API method that will just resturn resource status by<br>
> > UUID? Or even just extend get request with the new argument that returns<br>
> > only status?<br>
><br>
> I like the idea of being able pass in the set of fields you want to<br>
> see with each get. In SQL, often times only passing in indexed fields<br>
> will allow a query to be entirely serviced by a brief range scan in<br>
> the B-tree. For instance, if you have an index on '(UUID, status)',<br>
> then this lookup will be a single read from an index in MySQL/MariaDB:<br>
><br>
> SELECT status FROM instances WHERE UUID='foo';<br>
><br>
> The explain on this will say 'Using index' and basically you'll just do<br>
> a range scan on the UUID portion, and only find one entry, which will<br>
> be lightning fast, and return only status since it already has it there<br>
> in the index. Maintaining the index is not free, but probably worth it<br>
> if your users really do poll this way a lot.<br>
><br>
> That said, this is optimizing for polling, and I'm not a huge fan. I'd<br>
> much rather see a pub/sub model added to the API, so that users can<br>
> simply subscribe to changes in resources, and poll only when a very long<br>
> timeout has passed. This will reduce load on API services, databases,</p>
</div></div><p dir="ltr">++ this is a much better long term solution if we are investing engineering resources along these lines. </p><div class="HOEnZb"><div class="h5">
<p dir="ltr">> caches, etc. There was a thread some time ago about using Nova's built<br>
> in notifications to produce an Atom feed per-project. That seems like<br>
> a much more scalable model, as even polling just that super fast query<br>
> will still incur quite a bit more cost than a GET with If-Modified-Since<br>
> on a single xml file.<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>