<div dir="ltr">John, <div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im" style="font-size:12.8px">> Our resources are not. We've also had specific requests to prevent<br></span><span class="im" style="font-size:12.8px">> header bloat because it impacts the HTTP caching systems. Also, it's<br></span><span class="im" style="font-size:12.8px">> pretty clear that headers are really not where you want to put volatile<br></span><span class="im" style="font-size:12.8px">> information, which this is.</span><span class="im" style="font-size:12.8px"><br></span><span style="font-size:12.8px">Hmm, you do make a good point about caching.</span></blockquote><div><br></div><div><br></div><div>Caching is useful only in such cases when you would like to return same data many times. </div><div>In our case we are interested in latest state of resource, such kinds of things can't be cached. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im" style="font-size:12.8px">> I think we should step back here and figure out what the actual problem<br></span><span class="im" style="font-size:12.8px">> is, and what ways we might go about solving it. This has jumped directly<br></span><span class="im" style="font-size:12.8px">> to a point in time optimized fast poll loop. It will shave a few cycles<br></span><span class="im" style="font-size:12.8px">> off right now on our current implementation, but will still be orders of<br></span><span class="im" style="font-size:12.8px">> magnitude more costly that consuming the Nova notifications if the only<br></span><span class="im" style="font-size:12.8px">> thing that is cared about is task state transitions. And it's an API<br></span><span class="im" style="font-size:12.8px">> change we have to live with largely *forever* so short term optimization<br></span><span class="im" style="font-size:12.8px">> is not what we want to go for.</span><span class="im" style="font-size:12.8px"><br></span><span style="font-size:12.8px">I do agree with that.</span></blockquote><div><br></div><div>The thing here is that we have to have Async API, because we have long running operations. </div><div>And basically there are 3 approaches to understand that operation is done:</div><div>1) pub/sub</div><div>2) polling resource status</div><div>3) long polling requests</div><div><br></div><div>All approaches have pros and cons, however the "actual" problem will stay the same and you can't fix that..</div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 5, 2015 at 12:18 AM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 4 November 2015 at 15:00, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
> On 11/04/2015 09:49 AM, Jay Pipes wrote:<br>
>> On 11/04/2015 09:32 AM, Sean Dague wrote:<br>
>>> On 11/04/2015 09:00 AM, Jay Pipes wrote:<br>
>>>> On 11/03/2015 05:20 PM, Boris Pavlovic wrote:<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<br>
>>>>> the nature of this request. (Usually getting full information about<br>
>>>>> resources produces SQL requests that contains multiple JOINs, e,g for<br>
>>>>> nova vm it's 6 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<br>
>>>>> returns<br>
>>>>> only status?<br>
>>>><br>
>>>> +1<br>
>>>><br>
>>>> All APIs should have an HTTP HEAD call on important resources for<br>
>>>> retrieving quick status information for the resource.<br>
>>>><br>
>>>> In fact, I proposed exactly this in my Compute "vNext" API proposal:<br>
>>>><br>
>>>> <a href="http://docs.oscomputevnext.apiary.io/#reference/server/serversid/head" rel="noreferrer" target="_blank">http://docs.oscomputevnext.apiary.io/#reference/server/serversid/head</a><br>
>>>><br>
>>>> Swift's API supports HEAD for accounts:<br>
>>>><br>
>>>> <a href="http://developer.openstack.org/api-ref-objectstorage-v1.html#showAccountMeta" rel="noreferrer" target="_blank">http://developer.openstack.org/api-ref-objectstorage-v1.html#showAccountMeta</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> containers:<br>
>>>><br>
>>>> <a href="http://developer.openstack.org/api-ref-objectstorage-v1.html#showContainerMeta" rel="noreferrer" target="_blank">http://developer.openstack.org/api-ref-objectstorage-v1.html#showContainerMeta</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> and objects:<br>
>>>><br>
>>>> <a href="http://developer.openstack.org/api-ref-objectstorage-v1.html#showObjectMeta" rel="noreferrer" target="_blank">http://developer.openstack.org/api-ref-objectstorage-v1.html#showObjectMeta</a><br>
>>>><br>
>>>><br>
>>>> So, yeah, I agree.<br>
>>>> -jay<br>
>>><br>
>>> How would you expect this to work on "servers"? HEAD specifically<br>
>>> forbids returning a body, and, unlike swift, we don't return very much<br>
>>> information in our headers.<br>
>><br>
>> I didn't propose doing it on a collection resource like "servers". Only<br>
>> on an entity resource like a single "server".<br>
>><br>
>> HEAD /v2/{tenant}/servers/{uuid}<br>
>> HTTP/1.1 200 OK<br>
>> Content-Length: 1022<br>
>> Last-Modified: Thu, 16 Jan 2014 21:12:31 GMT<br>
>> Content-Type: application/json<br>
>> Date: Thu, 16 Jan 2014 21:13:19 GMT<br>
>> OpenStack-Compute-API-Server-VM-State: ACTIVE<br>
>> OpenStack-Compute-API-Server-Power-State: RUNNING<br>
>> OpenStack-Compute-API-Server-Task-State: NONE<br>
><br>
> Right, but these headers aren't in the normal resource. They are<br>
> returned in the body only.<br>
><br>
> The point of HEAD is give me the same thing as GET without the body,<br>
> because I only care about the headers. Swift resources are structured in<br>
> a way where this information is useful.<br>
<br>
</div></div>I guess we would have to add this to GET requests, for consistency,<br>
which feels like duplication.<br>
<span class=""><br>
> Our resources are not. We've also had specific requests to prevent<br>
> header bloat because it impacts the HTTP caching systems. Also, it's<br>
> pretty clear that headers are really not where you want to put volatile<br>
> information, which this is.<br>
<br>
</span>Hmm, you do make a good point about caching.<br>
<span class=""><br>
> I think we should step back here and figure out what the actual problem<br>
> is, and what ways we might go about solving it. This has jumped directly<br>
> to a point in time optimized fast poll loop. It will shave a few cycles<br>
> off right now on our current implementation, but will still be orders of<br>
> magnitude more costly that consuming the Nova notifications if the only<br>
> thing that is cared about is task state transitions. And it's an API<br>
> change we have to live with largely *forever* so short term optimization<br>
> is not what we want to go for.<br>
<br>
</span>I do agree with that.<br>
<span class=""><br>
> We should focus on the long term game here.<br>
<br>
</span>The long term plan being the end user async API? Maybe using<br>
websockets, or similar?<br>
<a href="https://etherpad.openstack.org/p/liberty-cross-project-user-notifications" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/liberty-cross-project-user-notifications</a><br>
<br>
Thanks,<br>
johnthetubaguy<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>