[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