Open Stack

On Mon Dec 01 2014 at 4:18:42 PM Thai Q Tran <tqtran at us.ibm.com> wrote:

> I agree that keeping the API layer thin would be ideal. I should add that
> having discrete API calls would allow dynamic population of table. However,
> I will make a case where it *might* be necessary to add additional APIs.
> Consider that you want to delete 3 items in a given table.
>
> If you do this on the client side, you would need to perform: n * (1 API
> request + 1 AJAX request)
> If you have some logic on the server side that batch delete actions: n *
> (1 API request) + 1 AJAX request
>
> Consider the following:
> n = 1, client = 2 trips, server = 2 trips
> n = 3, client = 6 trips, server = 4 trips
> n = 10, client = 20 trips, server = 11 trips
> n = 100, client = 200 trips, server 101 trips
>
> As you can see, this does not scale very well.... something to consider...
>
Yep, though in the above cases the client is still going to be hanging,
waiting for those server-backend calls, with no feedback until it's all
done. I would hope that the client-server call overhead is minimal, but I
guess that's probably wishful thinking when in the land of random Internet
users hitting some provider's Horizon :)

So yeah, having mulled it over myself I agree that it's useful to have
batch operations implemented in the POST handler, the most common operation
being DELETE.

Maybe one day we could transition to a batch call with user feedback using
a websocket connection.


     Richard

> [image: Inactive hide details for Richard Jones ---11/27/2014 05:38:53
> PM---On Fri Nov 28 2014 at 5:58:00 AM Tripp, Travis S <travis.tr]Richard
> Jones ---11/27/2014 05:38:53 PM---On Fri Nov 28 2014 at 5:58:00 AM Tripp,
> Travis S <travis.tripp at hp.com> wrote:
>
> From: Richard Jones <r1chardj0n3s at gmail.com>
> To: "Tripp, Travis S" <travis.tripp at hp.com>, OpenStack List <
> openstack-dev at lists.openstack.org>
> Date: 11/27/2014 05:38 PM
> Subject: Re: [openstack-dev] [horizon] REST and Django
> ------------------------------
>
>
>
>
> On Fri Nov 28 2014 at 5:58:00 AM Tripp, Travis S <*travis.tripp at hp.com*
> <travis.tripp at hp.com>> wrote:
>
>    Hi Richard,
>
>    You are right, we should put this out on the main ML, so copying
>    thread out to there.  ML: FYI that this started after some impromptu IRC
>    discussions about a specific patch led into an impromptu google hangout
>    discussion with all the people on the thread below.
>
>
> Thanks Travis!
>
>
>
>    As I mentioned in the review[1], Thai and I were mainly discussing the
>    possible performance implications of network hops from client to horizon
>    server and whether or not any aggregation should occur server side.   In
>    other words, some views  require several APIs to be queried before any data
>    can displayed and it would eliminate some extra network requests from
>    client to server if some of the data was first collected on the server side
>    across service APIs.  For example, the launch instance wizard will need to
>    collect data from quite a few APIs before even the first step is displayed
>    (I’ve listed those out in the blueprint [2]).
>
>    The flip side to that (as you also pointed out) is that if we keep the
>    API’s fine grained then the wizard will be able to optimize in one place
>    the calls for data as it is needed. For example, the first step may only
>    need half of the API calls. It also could lead to perceived performance
>    increases just due to the wizard making a call for different data
>    independently and displaying it as soon as it can.
>
>
> Indeed, looking at the current launch wizard code it seems like you
> wouldn't need to load all that data for the wizard to be displayed, since
> only some subset of it would be necessary to display any given panel of the
> wizard.
>
>
>
>    I tend to lean towards your POV and starting with discrete API calls
>    and letting the client optimize calls.  If there are performance problems
>    or other reasons then doing data aggregation on the server side could be
>    considered at that point.
>
>
> I'm glad to hear it. I'm a fan of optimising when necessary, and not
> beforehand :)
>
>
>
>    Of course if anybody is able to do some performance testing between
>    the two approaches then that could affect the direction taken.
>
>
> I would certainly like to see us take some measurements when performance
> issues pop up. Optimising without solid metrics is bad idea :)
>
>
>     Richard
>
>
>
>
>    [1]
>    *https://review.openstack.org/#/c/136676/8/openstack_dashboard/api/rest/urls.py*
>    <https://review.openstack.org/#/c/136676/8/openstack_dashboard/api/rest/urls.py>
>    [2]
>    *https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign*
>    <https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign>
>
>    -Travis
>
>    *From: *Richard Jones <*r1chardj0n3s at gmail.com*
>    <r1chardj0n3s at gmail.com>>
> * Date: *Wednesday, November 26, 2014 at 11:55 PM
> * To: *Travis Tripp <*travis.tripp at hp.com* <travis.tripp at hp.com>>, Thai Q
>    Tran/Silicon Valley/IBM <*tqtran at us.ibm.com* <tqtran at us.ibm.com>>,
>    David Lyle <*dklyle0 at gmail.com* <dklyle0 at gmail.com>>, Maxime Vidori <
>    *maxime.vidori at enovance.com* <maxime.vidori at enovance.com>>,
>    "Wroblewski, Szymon" <*szymon.wroblewski at intel.com*
>    <szymon.wroblewski at intel.com>>, "Wood, Matthew David (HP Cloud -
>    Horizon)" <*matt.wood at hp.com* <matt.wood at hp.com>>, "Chen, Shaoquan" <
>    *sean.chen2 at hp.com* <sean.chen2 at hp.com>>, "Farina, Matt (HP Cloud)" <
>    *matthew.farina at hp.com* <matthew.farina at hp.com>>, Cindy Lu/Silicon
>    Valley/IBM <*clu at us.ibm.com* <clu at us.ibm.com>>, Justin
>    Pomeroy/Rochester/IBM <*jpomero at us.ibm.com* <jpomero at us.ibm.com>>,
>    Neill Cox <*neill.cox at ingenious.com.au* <neill.cox at ingenious.com.au>>
> * Subject: *Re: REST and Django
>
>    I'm not sure whether this is the appropriate place to discuss this, or
>    whether I should be posting to the list under [Horizon] but I think we need
>    to have a clear idea of what goes in the REST API and what goes in the
>    client (angular) code.
>
>    In my mind, the thinner the REST API the better. Indeed if we can get
>    away with proxying requests through without touching any *client code, that
>    would be great.
>
>    Coding additional logic into the REST API means that a developer would
>    need to look in two places, instead of one, to determine what was happening
>    for a particular call. If we keep it thin then the API presented to the
>    client developer is very, very similar to the API presented by the
>    services. Minimum surprise.
>
>    Your thoughts?
>
>
>         Richard
>
>
>    On Wed Nov 26 2014 at 2:40:52 PM Richard Jones <
>    *r1chardj0n3s at gmail.com* <r1chardj0n3s at gmail.com>> wrote:
>
>
>    Thanks for the great summary, Travis.
>
>       I've completed the work I pledged this morning, so now the REST API
>       change set has:
>
>       - no rest framework dependency
>       - AJAX scaffolding in openstack_dashboard.api.rest.utils
>       - code in openstack_dashboard/api/rest/
>       - renamed the API from "identity" to "keystone" to be consistent
>       - added a sample of testing, mostly for my own sanity to check
>       things were working
>
>       *https://review.openstack.org/#/c/136676*
>       <https://review.openstack.org/#/c/136676>
>
>
>             Richard
>
>       On Wed Nov 26 2014 at 12:18:25 PM Tripp, Travis S <
>       *travis.tripp at hp.com* <travis.tripp at hp.com>> wrote:
>
>
>    Hello all,
>
>          Great discussion on the REST urls today! I think that we are on
>          track to come to a common REST API usage pattern.  To provide quick summary:
>
>          We all agreed that going to a straight REST pattern rather than
>          through tables was a good idea. We discussed using direct get / post in
>          Django views like what Max originally used[1][2] and Thai also started[3]
>          with the identity table rework or to go with djangorestframework [5] like
>          what Richard was prototyping with[4].
>
>          The main things we would use from Django Rest Framework were
>          built in JSON serialization (avoid boilerplate), better exception handling,
>          and some request wrapping.  However, we all weren’t sure about the need for
>          a full new framework just for that. At the end of the conversation, we
>          decided that it was a cleaner approach, but Richard would see if he could
>          provide some utility code to do that much for us without requiring the full
>          framework.  David voiced that he doesn’t want us building out a whole
>          framework on our own either.
>
>          So, Richard will do some investigation during his day today and
>          get back to us.  Whatever the case, we’ll get a patch in horizon for the
>          base dependency (framework or Richard’s utilities) that both Thai’s work
>          and the launch instance work is dependent upon.  We’ll build REST style
>          API’s using the same pattern.  We will likely put the rest api’s in
>          horizon/openstack_dashboard/api/rest/.
>
>          [1]
>          *https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/keypair.py*
>          <https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/keypair.py>
>          [2]
>          *https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/launch.py*
>          <https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/launch.py>
>          [3]
>          *https://review.openstack.org/#/c/133767/8/openstack_dashboard/dashboards/identity/users/views.py*
>          <https://review.openstack.org/#/c/133767/8/openstack_dashboard/dashboards/identity/users/views.py>
>          [4]
>          *https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py*
>          <https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py>
>          [5] *http://www.django-rest-framework.org/*
>          <http://www.django-rest-framework.org/>
>
>          Thanks,
>
>
>    Travis_______________________________________________
>          OpenStack-dev mailing list
>          OpenStack-dev at lists.openstack.org
>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20141202/83547fed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141202/83547fed/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141202/83547fed/attachment-0001.gif>