On 12/02/2014 12:39 AM, Richard Jones wrote:
On Mon Dec 01 2014 at 4:18:42 PM Thai Q Tran <tqt...@us.ibm.com
<mailto:tqt...@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.tr...@hp.com
<mailto:travis.tr...@hp.com>> wrote:
From: Richard Jones <r1chardj0...@gmail.com
<mailto:r1chardj0...@gmail.com>>
To: "Tripp, Travis S" <travis.tr...@hp.com
<mailto:travis.tr...@hp.com>>, OpenStack List
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@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@hp.com_ <mailto:travis.tr...@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@gmail.com_
<mailto:r1chardj0...@gmail.com>>*
Date: *Wednesday, November 26, 2014 at 11:55 PM*
To: *Travis Tripp <_travis.tripp@hp.com_
<mailto:travis.tr...@hp.com>>, Thai Q Tran/Silicon Valley/IBM
<_tqt...@us.ibm.com_ <mailto:tqt...@us.ibm.com>>, David Lyle
<_dklyle0@gmail.com_ <mailto:dkly...@gmail.com>>, Maxime
Vidori <_maxime.vidori@enovance.com_
<mailto:maxime.vid...@enovance.com>>, "Wroblewski, Szymon"
<_szymon.wroblewski@intel.com_
<mailto:szymon.wroblew...@intel.com>>, "Wood, Matthew David
(HP Cloud - Horizon)" <_matt.wood@hp.com_
<mailto:matt.w...@hp.com>>, "Chen, Shaoquan"
<_sean.chen2@hp.com_ <mailto:sean.ch...@hp.com>>, "Farina,
Matt (HP Cloud)" <_matthew.farina@hp.com_
<mailto:matthew.far...@hp.com>>, Cindy Lu/Silicon Valley/IBM
<_...@us.ibm.com_ <mailto:c...@us.ibm.com>>, Justin
Pomeroy/Rochester/IBM <_jpom...@us.ibm.com_
<mailto:jpom...@us.ibm.com>>, Neill Cox
<_neill....@ingenious.com.au_
<mailto:neill....@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@gmail.com_ <mailto:r1chardj0...@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@hp.com_ <mailto:travis.tr...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
