[openstack-dev] [Cinder] API features discoverability

2016-05-06 Thread D'Angelo, Scott
lopment Mailing List (not for usage questions) http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>> Subject: [openstack-dev] [Cinder] API features discoverability Hi, When looking at bug [1] I've thought that we could simply use /v2//extensions to signal features available in t

Re: [openstack-dev] [Cinder] API features discoverability

2016-04-20 Thread Duncan Thomas
On 19 April 2016 at 23:42, Michał Dulko wrote: > On 04/18/2016 09:17 AM, Ramakrishna, Deepti wrote: > > Hi Michal, > > > > This seemed like a good idea when I first read it. What more, the server > code for extension listing [1] does not do any authorization, so it can be > used for any logged in

Re: [openstack-dev] [Cinder] API features discoverability

2016-04-19 Thread Michał Dulko
atter. Do we have other OpenStack project suffering from similar issue? > > -Original Message- > From: Michał Dulko [mailto:michal.du...@intel.com] > Sent: Thursday, April 14, 2016 7:06 AM > To: OpenStack Development Mailing List (not for usage questions) > > Subj

Re: [openstack-dev] [Cinder] API features discoverability

2016-04-18 Thread Ramakrishna, Deepti
k.org/pipermail/openstack-dev/2015-October/077209.html [4] https://review.openstack.org/#/c/306930/ -Original Message- From: Michał Dulko [mailto:michal.du...@intel.com] Sent: Thursday, April 14, 2016 7:06 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [opensta

[openstack-dev] [Cinder] API features discoverability

2016-04-14 Thread Michał Dulko
Hi, When looking at bug [1] I've thought that we could simply use /v2//extensions to signal features available in the deployment - in this case backups, as these are implemented as API extension too. Cloud admin can disable an extension if his cloud doesn't support a particular feature and this is