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.ramakris...@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*). 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-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