Open Stack

On 4 November 2015 at 15:00, Sean Dague <sean at dague.net> wrote:
> On 11/04/2015 09:49 AM, Jay Pipes 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
>
> Right, but these headers aren't in the normal resource. They are
> returned in the body only.
>
> The point of HEAD is give me the same thing as GET without the body,
> because I only care about the headers. Swift resources are structured in
> a way where this information is useful.

I guess we would have to add this to GET requests, for consistency,
which feels like duplication.

> Our resources are not. We've also had specific requests to prevent
> header bloat because it impacts the HTTP caching systems. Also, it's
> pretty clear that headers are really not where you want to put volatile
> information, which this is.

Hmm, you do make a good point about caching.

> I think we should step back here and figure out what the actual problem
> is, and what ways we might go about solving it. This has jumped directly
> to a point in time optimized fast poll loop. It will shave a few cycles
> off right now on our current implementation, but will still be orders of
> magnitude more costly that consuming the Nova notifications if the only
> thing that is cared about is task state transitions. And it's an API
> change we have to live with largely *forever* so short term optimization
> is not what we want to go for.

I do agree with that.

> We should focus on the long term game here.

The long term plan being the end user async API? Maybe using
websockets, or similar?
https://etherpad.openstack.org/p/liberty-cross-project-user-notifications

Thanks,
johnthetubaguy