Open Stack

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>
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-request at 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/c24a1d4f/attachment.html>