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

David Chadwick d.w.chadwick at kent.ac.uk
Thu Aug 27 12:30:52 UTC 2015


Hi Henry

in principle I think it is a good idea to have a user friendly name
attribute for every entity. The name should be unique amongst the same
set of entities (though not between entities since context should imply
what entity you are referring to), otherwise the name would have to be
combined with the ID to identify it, and then you would loose the
usability advantage of having a name.

Eg. when setting up a mapping rule in Horizon it is more user friendly
to refer to domains and groups etc. using their user friendly names
rather than their IDs, even if the mapping rule requires the ID in JSON.

regards

David

On 26/08/2015 10:45, Henry Nash 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’).
> 
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list