Re: [openstack-dev] [Cinder] New extension API for detecting cinder-backup ?

2015-10-19 Thread Dulko, Michal 
On Fri, 2015-10-16 at 17:36 +, Ramakrishna, Deepti wrote:
> 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 
> 

I believe a BP and spec is required as this is a new API call added.
Also having a spec makes it easier to discuss whole idea with rest of
the team.
__
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

Re: [openstack-dev] [Cinder] New extension API for detecting cinder-backup ?

2015-10-16 Thread Ramakrishna, Deepti 
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.tho...@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" 
mailto: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<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-requ...@lists.openstack.org?subject:unsubscribe<http://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

Re: [openstack-dev] [Cinder] New extension API for detecting cinder-backup ?

2015-10-16 Thread Duncan Thomas 
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" 
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
> :
>
> "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
>  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
> ,
> 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

[openstack-dev] [Cinder] New extension API for detecting cinder-backup ?

2015-10-16 Thread Ramakrishna, Deepti 
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:
"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 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,
 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