> 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].
I think Henry's point is return everything or return nothing when there is a filter doesn't recognized by the server, let' s see the sample object in the spec [1], when there is a query like this, GET /app/items?bugus=buzz, will it return all the two items we have? I think this confuse the client developers a lot and give the user wrong indication, and the wrong direction based on the response, this seems to me more like a bug or something we need improvement. I agree that return 400 is good idea, thus client user would know what happened. Best Regards, Dave Chen > 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 > > > __________________________________________________________________________ > 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
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ 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
