Open Stack

Thanks Duncan.

Should I publish a BP and spec for this? And follow it up with code changes to the server, client, horizon and documentation?

Thanks,
Deepti

From: Duncan Thomas [mailto:duncan.thomas at gmail.com]
Sent: Friday, October 16, 2015 1:08 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Cinder] New extension API for detecting cinder-backup ?


I think option 2 is the better one, and we can just call it something else other than capabilities. Available_services or similar
On 16 Oct 2015 11:05, "Ramakrishna, Deepti" <deepti.ramakrishna at intel.com<mailto:deepti.ramakrishna at intel.com>> wrote:
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<http://%7bcinder-endpoint%7d/v2/%7btenant-id%7d/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


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151016/94629f1a/attachment.html>