In theory, for many cases, the service(s) will allow this to happen with ~1 
rest call.  I THINK this was a big part of the batch action code, atleast at 
the beginning, though I think we’ve (unfortunately) started moving away from 
that idea.
Matthew Wood
HP Cloud Services
Full-Stack Engineer
Python Lover

From: Thai Q Tran <><>
Reply: OpenStack Development Mailing List (not for usage questions) 
Date: November 30, 2014 at 10:20:29 PM
To: OpenStack Development Mailing List (not for usage questions) 
Subject:  Re: [openstack-dev] [horizon] REST and Django

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...

[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 <] Richard Jones ---11/27/2014 
05:38:53 PM---On Fri Nov 28 2014 at 5:58:00 AM Tripp, Travis S 
<> wrote:

From: Richard Jones <>
To: "Tripp, Travis S" <>, OpenStack List 
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 
<<>> 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 :)




From: Richard Jones <<>>
Date: Wednesday, November 26, 2014 at 11:55 PM
To: Travis Tripp <<>>, Thai Q 
Tran/Silicon Valley/IBM <<>>, David 
Lyle <<>>, Maxime Vidori 
<<>>, "Wroblewski, 
Szymon" <<>>, 
"Wood, Matthew David (HP Cloud - Horizon)" 
<<>>, "Chen, Shaoquan" 
<<>>, "Farina, Matt (HP Cloud)" 
<<>>, Cindy Lu/Silicon 
Valley/IBM <<>>, Justin 
Pomeroy/Rochester/IBM <<>>, Neill 
Cox <<>>
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) 

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 

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 

Your thoughts?


On Wed Nov 26 2014 at 2:40:52 PM Richard Jones 
<<>> wrote:
Thanks for the great summary, Travis.

I've completed the work I pledged this morning, so now the REST API change set 

- no rest framework dependency
- AJAX scaffolding in
- 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 


On Wed Nov 26 2014 at 12:18:25 PM Tripp, Travis S 
<<>> 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 

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 


OpenStack-dev mailing list

OpenStack-dev mailing list


OpenStack-dev mailing list

Reply via email to