> > 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’). > > > > I think OSC do this assumption based on that there is no need to query by the > ID. > 'openstack show' try to get the IDP by following, > curl -s -X GET > http://127.0.0.1:35357/v3/OS-FEDERATION/identity_providers/notexsitingIDP -H > "Content-Type: > application/json" -H "Accept: application/json" -H "X-Auth-Token: > 05e74f9448124aaba339cd809fd7b219" > > Then fail back to filter by the 'name'. In this case, if we allow the > per-entity definition, we may tried it again with the query > like this, > curl GET > http://127.0.0.1:35357/v3/OS-FEDERATION/identity_providers?id=notexsitingIDP > > but this is not necessary since we have tried it with the ID, why we still > tried it again with different API? the both APIs > *should* has the same response instead of > one get nothing and another get everything, this is not make sense. If there > is, this is a bug of the server IMO. > correct myself, both APIs will return nothing if allow per-entity definition in the OSC, but ID is tried two times.
Best Regards, Dave Chen > > > 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
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ 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
