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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
