[openstack-dev] [Cinder] API features discoverability

[D'Angelo, Scott]

I don't think we actually should be moving all the extensions to core, just the 
ones that are supported by all vendors and fully vetted. In other words, we 
should be moving extensions to core based on the original intent of extensions.
That would mean that for backups we could continue to use 
/v2|3//extensions to determine backup support (and anything else 
that is not supported by all vendors, and therefore in core).
As to whether or not the admin disables extensions that are not support by the 
deployment, I believe that admin should be responsible for their own 
deployment's UX.
Perhaps Deepti's new API has a use here, but I think it's worth discussing 
whether we can get the desired functionality out of the extensions, and whether 
we should strive to use extensions the way they were originally intended.

Scott (scottda)


Ramakrishna, Deepti deepti.ramakrishna at intel.com 
<mailto:openstack-dev%40lists.openstack.org?Subject=Re%3A%20%5Bopenstack-dev%5D%20%5BCinder%5D%20API%20features%20discoverability=%3CEEF613A4FA911D48911298B78DC42A533A65B666%40ORSMSX109.amr.corp.intel.com%3E>
Mon Apr 18 07:17:41 UTC 2016


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 user.

However, I don't know if requiring the admin to manually disable an extension 
is practical. First, admins
 can always forget to do that. Second, even if they wanted to, it is not clear 
how they could disable specific
 extensions. I assume they would need to edit the cinder.conf file. This file 
currently lists the set of
 extensions to load as cinder.api.contrib.standard_extensions. The server code 
[2] implements this by walking
 the cinder/api/contrib directory and loading all discovered extensions. How is 
it possible to subtract just
one extension from the "standard extensions"? Also, system capabilities and 
extensions may not have a 1:1
 relationship in general.

Having a new extension API (as proposed by me in [3]) for returning the 
available services/functionality does
 not have the above problems. It will dynamically check the existence of the 
cinder-backup service, so it does
 not need manual action from admin. I have published a BP [4] related to this. 
Can you please comment on that?

Thanks,
Deepti

[1] 
https://github.com/openstack/cinder/blob/2596004a542053bc19bb56b9a99f022368816871/cinder/api/extensions.py#L152
[2] 
https://github.com/openstack/cinder/blob/2596004a542053bc19bb56b9a99f022368816871/cinder/api/extensions.py#L312
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-October/077209.html
[4] https://review.openstack.org/#/c/306930/

-Original Message-
From: Michał Dulko [mailto:michal.dulko at 
intel.com<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>]
Sent: Thursday, April 14, 2016 7:06 AM
To: OpenStack Development 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 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 easily discoverable using
aforementioned call. Looks like that solution weren't proposed when the bug was 
initially raised.

Now the problem is that we're actually planning to move all API extensions to 
the core API. Do we plan to keep this
 API for features discovery? How to approach API compatibility in this case if 
we want to change it? Do we have a plan
 for that?

We could keep this extensions API controlled from the cinder.conf, regardless 
of the fact that we've moved everything
 to the core, but that doesn't seem right (API will still be functional, even 
if administrator disables it in configuration,
 am I right?)

Anyone have thoughts on that?

Thanks,
Michal

[1] https://bugs.launchpad.net/cinder/+bug/1334856


__
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] API features discoverability

[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 user.
> >
> > However, I don't know if requiring the admin to manually disable an
> extension is practical. First, admins can always forget to do that. Second,
> even if they wanted to, it is not clear how they could disable specific
> extensions. I assume they would need to edit the cinder.conf file. This
> file currently lists the set of extensions to load as
> cinder.api.contrib.standard_extensions. The server code [2] implements this
> by walking the cinder/api/contrib directory and loading all discovered
> extensions. How is it possible to subtract just one extension from the
> "standard extensions"? Also, system capabilities and extensions may not
> have a 1:1 relationship in general.
>
> Good point, to make that a standard for Cinder API feature discovery we
> would still need to make that more admin-friendly. This also implies
> that probably no admin is actually caring about setting the set of
> extensions correctly.
>

Certainly no no admins - the HP public cloud disabled a bunch of extensions
on the public endpoint for example - but it isn't something we can rely on.


> > Having a new extension API (as proposed by me in [3]) for returning the
> available services/functionality does not have the above problems. It will
> dynamically check the existence of the cinder-backup service, so it does
> not need manual action from admin. I have published a BP [4] related to
> this. Can you please comment on that?
>
> Yes, but I don't think you can run away from setting things manually.
> For example CGs are supported only for certain backends. This set of
> features should also be discoverable. Anyway I think the spec makes sense.
>

Volume type feature discovery is different (but related) to API feature
discovery.

This is unfortunately going against the recent efforts of standardizing
> how OpenStack works between deployments. In Cinder we have API features
> that may or may not be available in different installations. This
> certainly isn't addressed by microversions efforts, which may seem
> related. My feeling is that this goes beyond Cinder and hits a more
> general topic of API discoverability. I think that we should seek the
> API WG advice in that matter. Do we have other OpenStack project
> suffering from similar issue?
>
>
It's a nice aim to have clouds be entirely consistent, but then you're left
with the lowest common denominator. Replication and CG support in cinder
are both valuable to a subset of users, and extremely difficult to make
universal (I'm still hoping somebody can tell me why CGs at the hypervisor
are impossible to get right FWIW). Neutron is likely to be the largest
example of differentiated features, and manilla has some too.
__
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] API features discoverability

[Michał Dulko]

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 user.
>
> However, I don't know if requiring the admin to manually disable an extension 
> is practical. First, admins can always forget to do that. Second, even if 
> they wanted to, it is not clear how they could disable specific extensions. I 
> assume they would need to edit the cinder.conf file. This file currently 
> lists the set of extensions to load as 
> cinder.api.contrib.standard_extensions. The server code [2] implements this 
> by walking the cinder/api/contrib directory and loading all discovered 
> extensions. How is it possible to subtract just one extension from the 
> "standard extensions"? Also, system capabilities and extensions may not have 
> a 1:1 relationship in general.

Good point, to make that a standard for Cinder API feature discovery we
would still need to make that more admin-friendly. This also implies
that probably no admin is actually caring about setting the set of
extensions correctly.

> Having a new extension API (as proposed by me in [3]) for returning the 
> available services/functionality does not have the above problems. It will 
> dynamically check the existence of the cinder-backup service, so it does not 
> need manual action from admin. I have published a BP [4] related to this. Can 
> you please comment on that?

Yes, but I don't think you can run away from setting things manually.
For example CGs are supported only for certain backends. This set of
features should also be discoverable. Anyway I think the spec makes sense.

> Thanks,
> Deepti
>
> [1] 
> https://github.com/openstack/cinder/blob/2596004a542053bc19bb56b9a99f022368816871/cinder/api/extensions.py#L152
> [2] 
> https://github.com/openstack/cinder/blob/2596004a542053bc19bb56b9a99f022368816871/cinder/api/extensions.py#L312
> [3] 
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077209.html
> [4] https://review.openstack.org/#/c/306930/

This is unfortunately going against the recent efforts of standardizing
how OpenStack works between deployments. In Cinder we have API features
that may or may not be available in different installations. This
certainly isn't addressed by microversions efforts, which may seem
related. My feeling is that this goes beyond Cinder and hits a more
general topic of API discoverability. I think that we should seek the
API WG advice in that matter. 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) 
> <openstack-dev@lists.openstack.org>
> 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 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 easily discoverable using aforementioned call. Looks like 
> that solution weren't proposed when the bug was initially raised.
>
> Now the problem is that we're actually planning to move all API extensions to 
> the core API. Do we plan to keep this API for features discovery? How to 
> approach API compatibility in this case if we want to change it? Do we have a 
> plan for that?
>
> We could keep this extensions API controlled from the cinder.conf, regardless 
> of the fact that we've moved everything to the core, but that doesn't seem 
> right (API will still be functional, even if administrator disables it in 
> configuration, am I right?)
>
> Anyone have thoughts on that?
>
> Thanks,
> Michal
>
> [1] https://bugs.launchpad.net/cinder/+bug/1334856
>
> __
> 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

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

[Ramakrishna, Deepti]

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 user.

However, I don't know if requiring the admin to manually disable an extension 
is practical. First, admins can always forget to do that. Second, even if they 
wanted to, it is not clear how they could disable specific extensions. I assume 
they would need to edit the cinder.conf file. This file currently lists the set 
of extensions to load as cinder.api.contrib.standard_extensions. The server 
code [2] implements this by walking the cinder/api/contrib directory and 
loading all discovered extensions. How is it possible to subtract just one 
extension from the "standard extensions"? Also, system capabilities and 
extensions may not have a 1:1 relationship in general.

Having a new extension API (as proposed by me in [3]) for returning the 
available services/functionality does not have the above problems. It will 
dynamically check the existence of the cinder-backup service, so it does not 
need manual action from admin. I have published a BP [4] related to this. Can 
you please comment on that?

Thanks,
Deepti

[1] 
https://github.com/openstack/cinder/blob/2596004a542053bc19bb56b9a99f022368816871/cinder/api/extensions.py#L152
[2] 
https://github.com/openstack/cinder/blob/2596004a542053bc19bb56b9a99f022368816871/cinder/api/extensions.py#L312
[3] http://lists.openstack.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) 
<openstack-dev@lists.openstack.org>
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 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 easily discoverable using aforementioned call. Looks like that solution 
weren't proposed when the bug was initially raised.

Now the problem is that we're actually planning to move all API extensions to 
the core API. Do we plan to keep this API for features discovery? How to 
approach API compatibility in this case if we want to change it? Do we have a 
plan for that?

We could keep this extensions API controlled from the cinder.conf, regardless 
of the fact that we've moved everything to the core, but that doesn't seem 
right (API will still be functional, even if administrator disables it in 
configuration, am I right?)

Anyone have thoughts on that?

Thanks,
Michal

[1] https://bugs.launchpad.net/cinder/+bug/1334856

__
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] API features discoverability

[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 easily discoverable using
aforementioned call. Looks like that solution weren't proposed when the
bug was initially raised.

Now the problem is that we're actually planning to move all API
extensions to the core API. Do we plan to keep this API for features
discovery? How to approach API compatibility in this case if we want to
change it? Do we have a plan for that?

We could keep this extensions API controlled from the cinder.conf,
regardless of the fact that we've moved everything to the core, but that
doesn't seem right (API will still be functional, even if administrator
disables it in configuration, am I right?)

Anyone have thoughts on that?

Thanks,
Michal

[1] https://bugs.launchpad.net/cinder/+bug/1334856

__
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