[openstack-dev] [horizon] REST and Django

Adam Young ayoung at redhat.com
Tue Dec 2 14:45:30 UTC 2014

On 12/02/2014 12:39 AM, Richard Jones wrote:
> On Mon Dec 01 2014 at 4:18:42 PM Thai Q Tran <tqtran at us.ibm.com 
> <mailto: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...
This is not something Horizon can fix.  Horizon can make matters worse, 
but cannot make things better.

If you want to delete 3 users,   Horizon still needs to make 3 distinct 
calls to Keystone.

To fix this, we need either batch calls or a standard way to do 
multiples of the same operation.

The unified API effort it the right place to drive this.

> 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
>     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.trRichard 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
>     <mailto:travis.tripp at hp.com>> wrote:
>     From: Richard Jones <r1chardj0n3s at gmail.com
>     <mailto:r1chardj0n3s at gmail.com>>
>     To: "Tripp, Travis S" <travis.tripp at hp.com
>     <mailto:travis.tripp at hp.com>>, OpenStack List
>     <openstack-dev at lists.openstack.org
>     <mailto: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_ <mailto: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_
>         [2]
>         _https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign_
>         -Travis
>         *From: *Richard Jones <_r1chardj0n3s at gmail.com_
>         <mailto:r1chardj0n3s at gmail.com>>*
>         Date: *Wednesday, November 26, 2014 at 11:55 PM*
>         To: *Travis Tripp <_travis.tripp at hp.com_
>         <mailto:travis.tripp at hp.com>>, Thai Q Tran/Silicon Valley/IBM
>         <_tqtran at us.ibm.com_ <mailto:tqtran at us.ibm.com>>, David Lyle
>         <_dklyle0 at gmail.com_ <mailto:dklyle0 at gmail.com>>, Maxime
>         Vidori <_maxime.vidori at enovance.com_
>         <mailto:maxime.vidori at enovance.com>>, "Wroblewski, Szymon"
>         <_szymon.wroblewski at intel.com_
>         <mailto:szymon.wroblewski at intel.com>>, "Wood, Matthew David
>         (HP Cloud - Horizon)" <_matt.wood at hp.com_
>         <mailto:matt.wood at hp.com>>, "Chen, Shaoquan"
>         <_sean.chen2 at hp.com_ <mailto:sean.chen2 at hp.com>>, "Farina,
>         Matt (HP Cloud)" <_matthew.farina at hp.com_
>         <mailto:matthew.farina at hp.com>>, Cindy Lu/Silicon Valley/IBM
>         <_clu at us.ibm.com_ <mailto:clu at us.ibm.com>>, Justin
>         Pomeroy/Rochester/IBM <_jpomero at us.ibm.com_
>         <mailto:jpomero at us.ibm.com>>, Neill Cox
>         <_neill.cox at ingenious.com.au_
>         <mailto: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_ <mailto: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_
>                   Richard
>             On Wed Nov 26 2014 at 12:18:25 PM Tripp, Travis S
>             <_travis.tripp at hp.com_ <mailto: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_
>                 [2]
>                 _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_
>                 [4]
>                 _https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py_
>                 [5] _http://www.django-rest-framework.org/_
>                 Thanks,
>                 Travis_______________________________________________
>                 OpenStack-dev mailing list
>                 OpenStack-dev at lists.openstack.org
>                 <mailto: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
>     <mailto: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/9712330b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141202/9712330b/attachment.gif>

More information about the OpenStack-dev mailing list