<p dir="ltr"><br>
On Nov 3, 2015 4:29 PM, "Clint Byrum" <<a href="mailto:clint@fewbar.com">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>
<p dir="ltr">++ this is a much better long term solution if we are investing engineering resources along these lines. </p>
<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">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>