[openstack-dev] [Nova] [Horizon] Insufficient (?) features in current Nova API

Attila Fazekas afazekas at redhat.com
Fri Apr 10 13:20:02 UTC 2015


I think the Nova API (list) needs to be extended by custom attribute 
filtering and with multiple `server` get by uuid (up to 128+).
 
The basic list usually does not shows what I need.
nova processing more data than it is really needs just for a basic list.

The detailed list is very slow.

Maybe the attribute filtering or the multi item get(/POST) is not too RESTish thing,
but it can be very efficient! 


----- Original Message -----
> From: "Feodor Tersin" <ftersin at cloudscaling.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Friday, April 10, 2015 11:43:01 AM
> Subject: Re: [openstack-dev] [Nova] [Horizon] Insufficient (?) features in current Nova API
> 
> If you list instances with no details (detailed=False), it will increase
> performance. At least i hope for this.
> 
> On Fri, Apr 10, 2015 at 10:19 AM, Timur Sufiev < tsufiev at mirantis.com >
> wrote:
> 
> 
> 
> Chris, thank you for clearly rephrasing me. Yes, that is exactly what I
> meant.
> 
> On Fri, Apr 10, 2015 at 9:51 AM, Chris Friesen < chris.friesen at windriver.com
> > wrote:
> 
> 
> On 04/09/2015 10:13 PM, Monty Taylor wrote:
> 
> 
> On 04/09/2015 02:40 PM, Timur Sufiev wrote:
> 
> 
> Hello!
> 
> While analyzing Horizon behavior on a large scale we faced some performance
> issues which are most probably caused by inefficient calls to Nova API from
> Horizon, more specifically described at
> https://bugs.launchpad.net/ nova/+bug/1442310
> 
> Since my knowledge of Nova existing APIs is not very comprehensive I am not
> quite sure whether current Nova API indeed doesn't support requesting the
> details of a multiple instances limited by their <instance_id>-s (passed as
> part of `search_opts` parameter) or I just failed to find the proper REST
> call at http://developer.openstack. org/api-ref-compute-v2.1.html
> 
> Nova developers, could you please help me on that matter?
> 
> I recommend not trying to do any of that - but instead doing a 'list' to
> get the entire set of data and then filtering out the things you don't
> want client side.
> 
> The current code does what you recommend, but as mentioned in the bug report
> listed above they've run into performance issues.
> 
> They want to show the names for instances that cinder volumes are attached
> to, or that have floating IP addresses. Currently the retrieve the entire
> list of instances in order to get the names of the (potentially much
> smaller) set of instances that they actually care about.
> 
> If there was a "give me info on these specific instances" command in the nova
> API the above scenarios would be more efficient.
> 
> Chris
> 
> 
> 
> 
> 
> ______________________________ ______________________________ ______________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists. openstack.org?subject: unsubscribe
> http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-dev
> 
> 
> 
> --
> Timur Sufiev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list