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