Mark T. Voelker
> On Sep 29, 2015, at 12:36 PM, Matt Fischer <m...@mattfischer.com> wrote: > > > > I agree with John Griffith. I don't have any empirical evidences to back > my "feelings" on that one but it's true that we weren't enable to enable > Cinder v2 until now. > > Which makes me wonder: When can we actually deprecate an API version? I > *feel* we are fast to jump on the deprecation when the replacement isn't > 100% ready yet for several versions. > > -- > Mathieu > > > I don't think it's too much to ask that versions can't be deprecated until > the new version is 100% working, passing all tests, and the clients (at least > python-xxxclients) can handle it without issues. Ideally I'd like to also > throw in the criteria that devstack, rally, tempest, and other services are > all using and exercising the new API. > > I agree that things feel rushed. FWIW, the TC recently created an assert:follows-standard-deprecation tag. Ivan linked to a thread in which Thierry asked for input on it, but FYI the final language as it was approved last week [1] is a bit different than originally proposed. It now requires one release plus 3 linear months of deprecated-but-still-present-in-the-tree as a minimum, and recommends at least two full stable releases for significant features (an entire API version would undoubtedly fall into that bucket). It also requires that a migration path will be documented. However to Matt’s point, it doesn’t contain any language that says specific things like: In the case of major API version deprecation: * $oldversion and $newversion must both work with [cinder|nova|whatever]client and openstackclient during the deprecation period. * It must be possible to run $oldversion and $newversion concurrently on the servers to ensure end users don’t have to switch overnight. * Devstack uses $newversion by default. * $newversion works in Tempest/Rally/whatever else. What it *does* do is require that a thread be started here on openstack-operators [2] so that operators can provide feedback. I would hope that feedback like “I can’t get clients to use it so please don’t remove it yet” would be taken into account by projects, which seems to be exactly what’s happening in this case with Cinder v1. =) I’d hazard a guess that the TC would be interested in hearing about whether you think that plan is a reasonable one (and given that TC election season is upon us, candidates for the TC probably would too). [1] https://review.openstack.org/#/c/207467/ [2] http://git.openstack.org/cgit/openstack/governance/tree/reference/tags/assert_follows-standard-deprecation.rst#n59 At Your Service, Mark T. Voelker > > > __________________________________________________________________________ > 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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
