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’).

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?

Thanks

Henry
Keystone Core

__________________________________________________________________________
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

Reply via email to