On Thu, Aug 27, 2015 at 11:47 AM, Everett Toews <everett.to...@rackspace.com > wrote:
> On Aug 26, 2015, at 4:45 AM, Henry Nash <hen...@linux.vnet.ibm.com> wrote: > > > Hi > > > > With keystone, we recently came across an issue in terms of the > assumptions that the openstack client is making about the entities it can > show - namely that is assumes all entries have a ‘name’ attribute (which is > how the "openstack show" command works). Turns out, that not all keystone > entities have such an attribute (e.g. IDPs for federation) - often the ID > is really the name. Is there already agreement across our APIs that all > first class entities should have a ‘name’ attribute? If we do, then we > need to change keystone, if not, then we need to change openstack client to > not make this assumption (and perhaps allow some kind of per-entity > definition of which attribute should be used for ‘show’). > > AFAICT, there’s no such agreement in the API WG guidelines [1]. > > > A follow on (and somewhat related) question to this, is whether we have > agreed standards for what should happen if some provides an unrecognized > filter to a list entities API request at the http level (this is related > since this is also the hole osc fell into with keystone since, again, > ‘name’ is not a recognized filter attribute). Currently keystone ignores > filters it doesn’t understand (so if that was your only filter, you would > get back all the entities). The alternative approach would of course be to > return no entities if the filter is on an attribute we don’t recognize (or > even issue a validation or bad request exception). Again, the question is > whether we have agreement across the projects for how such unrecognized > filtering should be handled? > > The closest thing we have is the Filtering guideline [2] but it doesn’t > account for this particular case. > > Client tool developers would be quite frustrated by a service ignoring > filters it doesn’t understand or returning no entities if the filter isn’t > recognized. In both cases, the developer isn’t getting the expected result > but you’re masking the error made by the developer. > > Much better to return a 400 so the problem can be fixed immediately. > Somewhat related is this draft [3]. > > Everett > > [1] http://specs.openstack.org/openstack/api-wg/ > [2] > http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering > [3] https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 There are two different things being talked about here (I think). 1) The unknown filter as Everett has outlined would be something like 'filter_type' as a regex and the service has no idea what that filter type is. This should be a 400 as the server cannot handle/know how to process that type of filter. 2) What Henry was discussing is asking for an filter on an entity with a known filter type (e.g. string match) where the entity doesn't have the field. An example is the list of IDPs where there is no name field. Should case 2 be a 400? Or an empty list. You've asked to filter on name, nothing can match since there is no name. I'm not opposed to case #2 being an explicit 400 either, just want to outline the difference clearly here so we are talking the same things. Feel free to let me know I misread any of the comments so far :) --Morgan
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev