Open Stack

Sean,

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 totally agree on this. We shouldn't add a lot of HTTP headers. Imho why
not just return in body string with status (in my case).


> I think longer term we probably need a dedicated event service in
> OpenStack.


Unfortunately, this will work slower then current solution with JOINs,
require more resources and it will be very hard to use... (like you'll need
to add one more service to openstack, and use one more client..)


Best regards,
Boris Pavlovic


On Thu, Nov 5, 2015 at 12:42 AM, Sean Dague <sean at dague.net> wrote:

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151105/ddf7bd4f/attachment.html>