[openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

Chris Friesen chris.friesen at windriver.com
Wed Nov 4 06:06:12 UTC 2015


On 11/03/2015 11:45 PM, John Griffith wrote:
>
>
> On Tue, Nov 3, 2015 at 3:20 PM, Boris Pavlovic <boris at pavlovic.me
> <mailto:boris at pavlovic.me>> wrote:
>
>     Hi stackers,
>
>     Usually such projects like Heat, Tempest, Rally, Scalar, and other tool that
>     works with OpenStack are working with resources (e.g. VM, Volumes, Images,
>     ..) in the next way:
>
>      >>> resource = api.resouce_do_some_stuff()
>      >>> while api.resource_get(resource["uuid"]) != expected_status
>      >>>    sleep(a_bit)
>
>     For each async operation they are polling and call many times resource_get()
>     which creates significant load on API and DB layers due the nature of this
>     request. (Usually getting full information about resources produces SQL
>     requests that contains multiple JOINs, e,g for nova vm it's 6 joins).
>
>     What if we add new API method that will just resturn resource status by
>     UUID? Or even just extend get request with the new argument that returns
>     only status?

> ​Hey Boris,
>
> As I asked in IRC, I'm kinda curious what the difference is here in terms of API
> and DB calls.  I very well might be missing an idea here, but currently we do a
> get by ID in that loop that you mention, the only difference I see in what
> you're suggesting is a reduced payload maybe?  A response that only includes the
> status?
>
> I may be missing an important idea here, but it seems to me that you would still
> have the same number of API calls and DB request, just possibly a slightly
> smaller payload.  Let me know if I'm missing the idea here.


I think the idea is that we would only retrieve resource status rather than the 
full information about the resource.  In doing so we would:

1) Reduce the load on the DB due to doing fewer JOINs and retrieving less data.
2) Reduce the message payload.

I suspect that the first one is more important.

Chris



More information about the OpenStack-dev mailing list