Open Stack

> 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].

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6648 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150828/fee2124f/attachment.bin>