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