Open Stack

On 11/04/2015 10:13 AM, John Garbutt wrote:
> On 4 November 2015 at 14:49, Jay Pipes <jaypipes at gmail.com> wrote:
>> On 11/04/2015 09:32 AM, Sean Dague wrote:
>>>
>>> On 11/04/2015 09:00 AM, Jay Pipes wrote:
>>>>
>>>> On 11/03/2015 05:20 PM, Boris Pavlovic 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?
>>>>
>>>>
>>>> +1
>>>>
>>>> All APIs should have an HTTP HEAD call on important resources for
>>>> retrieving quick status information for the resource.
>>>>
>>>> In fact, I proposed exactly this in my Compute "vNext" API proposal:
>>>>
>>>> http://docs.oscomputevnext.apiary.io/#reference/server/serversid/head
>>>>
>>>> Swift's API supports HEAD for accounts:
>>>>
>>>>
>>>> http://developer.openstack.org/api-ref-objectstorage-v1.html#showAccountMeta
>>>>
>>>>
>>>> containers:
>>>>
>>>>
>>>> http://developer.openstack.org/api-ref-objectstorage-v1.html#showContainerMeta
>>>>
>>>>
>>>> and objects:
>>>>
>>>>
>>>> http://developer.openstack.org/api-ref-objectstorage-v1.html#showObjectMeta
>>>>
>>>> So, yeah, I agree.
>>>> -jay
>>>
>>>
>>> How would you expect this to work on "servers"? HEAD specifically
>>> forbids returning a body, and, unlike swift, we don't return very much
>>> information in our headers.
>>
>>
>> I didn't propose doing it on a collection resource like "servers". Only on
>> an entity resource like a single "server".
>>
>> HEAD /v2/{tenant}/servers/{uuid}
>> HTTP/1.1 200 OK
>> Content-Length: 1022
>> Last-Modified: Thu, 16 Jan 2014 21:12:31 GMT
>> Content-Type: application/json
>> Date: Thu, 16 Jan 2014 21:13:19 GMT
>> OpenStack-Compute-API-Server-VM-State: ACTIVE
>> OpenStack-Compute-API-Server-Power-State: RUNNING
>> OpenStack-Compute-API-Server-Task-State: NONE
> 
> For polling, that sounds quite efficient and handy.
> 
> For "servers" we could do this (I think there was a spec up that wanted this):
> 
> HEAD /v2/{tenant}/servers
> HTTP/1.1 200 OK
> Content-Length: 1022
> Last-Modified: Thu, 16 Jan 2014 21:12:31 GMT
> Content-Type: application/json
> Date: Thu, 16 Jan 2014 21:13:19 GMT
> OpenStack-Compute-API-Server-Count: 13

This seems like a fundamental abuse of HTTP honestly. If you find
yourself creating a ton of new headers, you are probably doing it wrong.

I do think the near term work around is to actually use Searchlight.
They're monitoring the notifications bus for nova, and refreshing
resources when they see a notification which might have changed it. It
still means that Searchlight is hitting our API more than ideal, but at
least only one service is doing so, and if the rest hit that instead
they'll get the resource without any db hits (it's all through an
elastic search cluster).

I think longer term we probably need a dedicated event service in
OpenStack. A few of us actually had an informal conversation about this
during the Nova notifications session to figure out if there was a way
to optimize the Searchlight path. Nearly everyone wants websockets,
which is good. The problem is, that means you've got to anticipate
10,000+ open websockets as soon as we expose this. Which means the stack
to deliver that sanely isn't just a bit of python code, it's also the
highly optimized server underneath.

So, I feel like with Searchlight we've got a work around that's more
efficient than we're going to make with an API that we really don't want
to support down the road. Because I definitely don't want to make
general purpose search a thing inside every service, as in order to make
it efficient we're going to have to reimplement most of searchlight in
the services.

Instead of spending the energy on this path, it would be much better to
push forward on the end user events path, which is really the long term
model we want.

	-Sean

-- 
Sean Dague
http://dague.net