Open Stack

> > 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-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/ddb4ccc1/attachment.bin>