<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 27, 2015 at 11:47 AM, Everett Toews <span dir="ltr"><<a href="mailto:everett.toews@rackspace.com" target="_blank">everett.toews@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Aug 26, 2015, at 4:45 AM, Henry Nash <<a href="mailto:henryn@linux.vnet.ibm.com">henryn@linux.vnet.ibm.com</a>> wrote:<br>
<br>
> Hi<br>
><br>
> 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’).<br>
<br>
</span>AFAICT, there’s no such agreement in the API WG guidelines [1].<br>
<span class=""><br>
> 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?<br>
<br>
</span>The closest thing we have is the Filtering guideline [2] but it doesn’t account for this particular case.<br>
<br>
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.<br>
<br>
Much better to return a 400 so the problem can be fixed immediately. Somewhat related is this draft [3].<br>
<br>
Everett<br>
<br>
[1] <a href="http://specs.openstack.org/openstack/api-wg/" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/api-wg/</a><br>
[2] <a href="http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering</a><br>
[3] <a href="https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00</a></blockquote><div><br></div><div>There are two different things being talked about here (I think). <br><br>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.<br><br></div><div>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. <br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>Feel free to let me know I misread any of the comments so far :)<br><br></div><div>--Morgan <br></div></div></div></div>