Open Stack

Hi,

We need a way to let Horizon know about the presence of cinder-backup service so that it can enable the volume backup operations in the UI (https://bugs.launchpad.net/cinder/+bug/1334856).

The backup action does not have any restrictions on who can perform it as evidenced by the following policy in etc/cinder/policy.json<https://github.com/openstack/cinder/blob/master/etc/cinder/policy.json>:
"backup:create" : ""

However, the only API that can tell Horizon about the existence of this service, namely the "os-services" API extension (that corresponds to the "cinder service-list" client command) is admin-only:
"volume_extension:services:index": "rule:admin_api"

Today, Horizon uses<http://docs.openstack.org/developer/horizon/topics/settings.html> a config setting "enable_backup", that needs to be manually set in order to enable backup functionality in Horizon. We need a way for Horizon to figure this out itself, programmatically.

I can think of two ways:

  1.  Modify the services:index action to take a details=true/false parameter (http://{cinder-endpoint}/v2/{tenant-id}/os-services?details=false). And define different policies for detail=true(admin_api) and detail=false ("" i.e. unrestricted).

     *   "volume_extension:services:index_with_details": "rule:admin_api"
     *   "volume_extension:services:index_without_details": ""
  1.  Raise the abstraction level by creating a Cinder API extension that returns the list of "service capabilities". That is, the list of functionality that the cinder service supports. This will return only "volume backup" for now but can be augmented as new capabilities are added to Cinder.

I don't know if #1 can be implemented in a backward compatible way and also whether there is precedence for splitting the policy of a single API call based on parameters.
#2 seems the traditional way to do it, but I am afraid that "service capabilities" terminology clashes with existing "volume capabilities" extension<https://github.com/openstack/cinder/blob/master/cinder/api/contrib/capabilities.py>, which has a different purpose.

I would appreciate any input on this.

Thanks,
Deepti

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151016/f59e59fd/attachment.html>