[openstack-dev] [Cinder] API features discoverability
michal.dulko at intel.com
Thu Apr 14 14:06:10 UTC 2016
When looking at bug  I've thought that we could simply use
/v2/<tenant-id>/extensions to signal features available in the
deployment - in this case backups, as these are implemented as API
extension too. Cloud admin can disable an extension if his cloud doesn't
support a particular feature and this is easily discoverable using
aforementioned call. Looks like that solution weren't proposed when the
bug was initially raised.
Now the problem is that we're actually planning to move all API
extensions to the core API. Do we plan to keep this API for features
discovery? How to approach API compatibility in this case if we want to
change it? Do we have a plan for that?
We could keep this extensions API controlled from the cinder.conf,
regardless of the fact that we've moved everything to the core, but that
doesn't seem right (API will still be functional, even if administrator
disables it in configuration, am I right?)
Anyone have thoughts on that?
More information about the OpenStack-dev