as a general principle I would think it is a good idea for clients to be
able to interrogate Keystone to determine what extensions it supports.
Most protocols have some mechanism for determining what
extensions/versions are supported by the server, and what optional
features are implemented.
regards
David
On 06/08/2013 06:19, Jamie Lennox wrote:
Hi all,
Partially in response to the trusts API review in keystoneclient
(https://review.openstack.org/#/c/39899/ ) and my work on keystone API
version discoverability (spell-check disagrees but I'm going to assume
that's a word - https://review.openstack.org/#/c/38414/ ) I was thinking
about how we should be able to know what/if an extension is available. I
even made a basic blueprint for how i think it should work:
https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions
and then realized that GET /extensions is only a V2 API.
Is this intentional? I was starting to make a review to add it to
identity-api but is there the intention that extensions should show up
within the endpoint APIs? There is no reason it couldn't work that way
and DELETE would just fail.
I am not convinced that it is a good idea though and I just want to
check if this is something that has been discussed or purposefully
handled this way or something we need to add.
Thanks,
Jamie
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
