Open Stack

 ---- On Wed, 28 Jul 2021 15:50:07 -0500 Brian Rosmaita <rosmaita.fossdev at gmail.com> wrote ----
 > 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.

The main purpose of the 'assert:follows-standard-deprecation'  tag is
to avoid breaking user without deprecation notification and they upgrade
to new code base keep working with their existing configuration.

In cinder case, v2 API was deprecated long back so any related/associated
config options, RBAC policies etc are understood to be deprecated and gone
along with v2 code base.

As you mentioned, keeping or removing  'enable_v3_api'  is no meaning now. I do
not think keeping it deprecated for a cycle but saying it has 'no meaning' make much
sense. If there was any way for users to enable v2 via this config option then deprecation
could have make sense.

IMO, this is just missed in deprecation documentation of this config option when you
deprecated v2 but it is clearly meant to be removed along with v2. I do not find any
issue to remove it along with v2 code itself and I do not think it violate the tag, it is
just documentation miss. 

-gmann

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