I don't think we actually should be moving all the extensions to core, just the ones that are supported by all vendors and fully vetted. In other words, we should be moving extensions to core based on the original intent of extensions. That would mean that for backups we could continue to use /v2|3/<tenant-id>/extensions to determine backup support (and anything else that is not supported by all vendors, and therefore in core). As to whether or not the admin disables extensions that are not support by the deployment, I believe that admin should be responsible for their own deployment's UX. Perhaps Deepti's new API has a use here, but I think it's worth discussing whether we can get the desired functionality out of the extensions, and whether we should strive to use extensions the way they were originally intended.
Scott (scottda) Ramakrishna, Deepti deepti.ramakrishna at intel.com <mailto:openstack-dev%40lists.openstack.org?Subject=Re%3A%20%5Bopenstack-dev%5D%20%5BCinder%5D%20API%20features%20discoverability&In-Reply-To=%3CEEF613A4FA911D48911298B78DC42A533A65B666%40ORSMSX109.amr.corp.intel.com%3E> Mon Apr 18 07:17:41 UTC 2016 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. 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? 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/ -----Original Message----- From: Michał Dulko [mailto:michal.dulko at intel.com<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>] Sent: Thursday, April 14, 2016 7:06 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
