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 __________________________________________________________________________ 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
