Open Stack

Hi Gabriel,

Following up on our discussions on filtering and pagination, here's where we stand:

1) We have a patch ready to go into H that implements a framework that lets the keystone backend drivers implement filters (e.g. would be included in the SQL SELECT rather than being a post-prcessed filter on the full list, which is what happens today).  See: https://review.openstack.org/#/c/43257/ . It includes the SQL drivers fixed up so they work with this, although it's unlikely we can get the LDAP one complete for H given the freeze (which just means queries to an LDAP backed entity will just work as they do today).
2) The above patch also lets a cloud provider set a limit on the number of rows return by a list query, to avoid excessively long responses and data in the case where the caller doesn't do a good job of filtering.

We have two other changes ready, but are deferring to IceHouse:

3) The inexact filtering (e.g. GET /v3/users?name__startswitch=Hen) is coded and included in 1).  However, since this is an API change we have it turned off, and will enable early in IceHouse.  An API review for this is already posted (with you as one of the reviewers): https://review.openstack.org/#/c/43900/
4) A separate patch is also ready for Pagination (https://review.openstack.org/#/c/43581/), using the simple page and per_page semantics.  Given the contention over this, we'll discuss this at the HK summit

I wanted to gauge how advantageous 1) and 2) are to you and the Horizon team?  Some concerns have been raised (given how close we are to the freeze) as to whether we should push them in.  Personally I'm OK with it, but wanted to balance that with real need (or not if you see these as only minor).

Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130828/0b1707e1/attachment.html>