Open Stack

On Thu, Aug 27, 2015 at 11:47 AM, Everett Toews <everett.toews at rackspace.com
> wrote:

> On Aug 26, 2015, at 4:45 AM, Henry Nash <henryn at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150827/f30e3ef6/attachment.html>