Open Stack

While these are useful steps in isolation, I'm hesitant to just say "go for it!" because I see this as a problem that OpenStack as a whole needs to solve. Your implementation here is a good proof-of-concept that's likely worth vetting and then emulating elsewhere.

However looking at it a different way it adds further fragmentation to the filtering, sorting, paging, etc. methods that Horizon has to attempt to support across all the projects.

It's my intention to run a session on this at the summit and probably walk out of that summit with a "Horizon will support X, so if you want people to have a good experience with your project in Horizon you should support X too" kind of agreement that we can work towards across projects in Icehouse. That X will likely reflect what you've done here and the great discussions that happened recently about the possibility of doing away with pagination entirely.

If the patch is ready to go then by all means merge it and we can start playing with it to see where it shines and where it needs polish. I'm all for it in principle.

All the best,


-          Gabriel

From: Henry Nash [mailto:henryn at linux.vnet.ibm.com]
Sent: Wednesday, August 28, 2013 1:58 AM
To: Gabriel Hurley
Cc: OpenStack Development Mailing List; Dolph Mathews; Adam Young
Subject: [keystone][horizon]Backend filtering in Keystone

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/a919092e/attachment.html>