[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
