[openstack-dev] [nova] Boston Forum session recap - searchlight integration

Matt Riedemann mriedemos at gmail.com
Fri May 19 13:23:21 UTC 2017

On 5/19/2017 1:46 AM, joehuang wrote:
> Support sort and pagination together will be the biggest challenge: it's up to how many cells will be involved in the query, 3,5 may be OK, you can search each cells, and cached data. But how about 20, 50 or more, and how many data will be cached?
> More over, during the query there are instances operation( create, delete)  in parallel during the pagination/sort query, there is situation some cells may not provide response in time, or network connection broken, etc, many abnormal cases may happen. How to deal with some of cells abnormal query response is also one great factor to be considered.

I think we've always stated that paging and sorting is not guaranteed to 
be perfect. With paging the marker is the last instance uuid in the last 
page, and if you create a new instance before querying for the next 
page, you might not find that new instance in the results. I don't think 
integrating searchlight is going to fix that as there is still latency 
in getting the new instance.create event results to searchlight so it's 

> It's not good idea to support pagination and sort at the same time (may not provide exactly the result end user want) if searchlight should not be integrated.

As noted above, I don't see how Searchlight is going to fix the 
"instance created while in the middle of paging" issue. Searchlight may 
increase the performance of querying a large number of instances across 
dozens of cells, yes, that was the point in going down this path in the 
first place.

> In fact in Tricircle, when query ports from neutron where tricircle central plugin is installed, the tricircle central plugin do the similar cross local Neutron ports query, and not support pagination/sort together.

Doesn't that break the contract on the networking API if paging/sorting 
isn't supported when using Tricircle but it is supported when using 
Neutron's networking API directly? It's my understanding that Tricircle 
(and Cascading before it) are proxies to separate OpenStack deployments, 
which can be at various versions (maybe one deployment is mitaka, others 
are newton). But I would expect that the end user facing API is 
compatible with the native APIs, or is that not the case - and users 
understand that when using Tricircle / Cascading? If so, then how do 
libraries/SDKs and CLIs like openstackclient work with Tricircle?

The point of what we're trying to do in nova is expose the same API and 
honor it regardless of whether or not you're using a single cell or 10 
cells - it should be transparent to the end user of the cloud.




More information about the OpenStack-dev mailing list