On 04/18/2016 09:17 AM, Ramakrishna, Deepti wrote: > Hi Michal, > > This seemed like a good idea when I first read it. What more, the server code > for extension listing [1] does not do any authorization, so it can be used > for any logged in user. > > However, I don't know if requiring the admin to manually disable an extension > is practical. First, admins can always forget to do that. Second, even if > they wanted to, it is not clear how they could disable specific extensions. I > assume they would need to edit the cinder.conf file. This file currently > lists the set of extensions to load as > cinder.api.contrib.standard_extensions. The server code [2] implements this > by walking the cinder/api/contrib directory and loading all discovered > extensions. How is it possible to subtract just one extension from the > "standard extensions"? Also, system capabilities and extensions may not have > a 1:1 relationship in general.
Good point, to make that a standard for Cinder API feature discovery we would still need to make that more admin-friendly. This also implies that probably no admin is actually caring about setting the set of extensions correctly. > Having a new extension API (as proposed by me in [3]) for returning the > available services/functionality does not have the above problems. It will > dynamically check the existence of the cinder-backup service, so it does not > need manual action from admin. I have published a BP [4] related to this. Can > you please comment on that? Yes, but I don't think you can run away from setting things manually. For example CGs are supported only for certain backends. This set of features should also be discoverable. Anyway I think the spec makes sense. > Thanks, > Deepti > > [1] > https://github.com/openstack/cinder/blob/2596004a542053bc19bb56b9a99f022368816871/cinder/api/extensions.py#L152 > [2] > https://github.com/openstack/cinder/blob/2596004a542053bc19bb56b9a99f022368816871/cinder/api/extensions.py#L312 > [3] > http://lists.openstack.org/pipermail/openstack-dev/2015-October/077209.html > [4] https://review.openstack.org/#/c/306930/ This is unfortunately going against the recent efforts of standardizing how OpenStack works between deployments. In Cinder we have API features that may or may not be available in different installations. This certainly isn't addressed by microversions efforts, which may seem related. My feeling is that this goes beyond Cinder and hits a more general topic of API discoverability. I think that we should seek the API WG advice in that matter. Do we have other OpenStack project suffering from similar issue? > > -----Original Message----- > From: Michał Dulko [mailto:michal.du...@intel.com] > Sent: Thursday, April 14, 2016 7:06 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [Cinder] API features discoverability > > Hi, > > When looking at bug [1] 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? > > Thanks, > Michal > > [1] https://bugs.launchpad.net/cinder/+bug/1334856 > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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