[openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

Henry Nash henryn at linux.vnet.ibm.com
Wed Aug 26 09:45:50 UTC 2015


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



More information about the OpenStack-dev mailing list