Open Stack

Hello TC members,

Cinder has asserted the 'assert:follows-standard-deprecation' tag.  This 
cycle, the long-deprecated Block Storage API v2 has been removed [0], at 
which time the 'enable_v2_api' option was also removed (which was 
appropriate since the option had been deprecated since Mitaka [1]).

It turns out, however, that the corresponding 'enable_v3_api' option had 
never been deprecated.  It has been deprecated in the current 
development branch by [0], but the team would like to know whether it is 
permissible to simply remove it in Xena without deprecating it for the 
following reasons:

- The option was introduced by [1] in Mitaka.  It has always had the 
default value: True.

- In the Xena release, if the option is False, you can deploy the Block 
Storage API, but the only reachable resource from the endpoint is 
'/versions', which returns an empty list of available versions.  This 
doesn't seem to be something that anyone would do on purpose.

- If someone wants to deploy only the Block Storage API v2, this cannot 
be done in Xena by setting 'enable_v3_api' to False.  So for that 
purpose, this option is already effectively a no-op in Xena.

In short, we could leave the 'enable_v3_api' option as deprecated in the 
Xena release, but we can't imagine any circumstances under which someone 
would intentionally use it in its non-default value, so it seems 
pointless to keep it around ... except to satisfy the 
'assert:follows-standard-deprecation' tag.

To be clear, the Cinder team has no intention of violating or removing 
the 'assert:follows-standard-deprecation' tag.  The point of this email 
is to ask the TC whether it would be permissible to simply remove the 
'enable_v3_api' option in Xena (as opposed to deprecating the option in 
Xena and then waiting until Yoga development to remove it).

Thanks for thinking about this!


[0] https://review.opendev.org/c/openstack/cinder/+/792299
[1] https://review.opendev.org/c/openstack/cinder/+/224910