This is now queued up for discussion this week - https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda
On 10/01/2015 06:22 AM, Sean Dague wrote: > Some of us are actively watching the thread / participating. I'll make > sure it gets on the TC agenda in the near future. > > I think most of the recommendations are quite good, especially on the > client support front for clients / tools within our community. > > On 09/30/2015 10:37 PM, Matt Fischer wrote: >> Thanks for summarizing this Mark. What's the best way to get feedback >> about this to the TC? I'd love to see some of the items which I think >> are common sense for anyone who can't just blow away devstack and start >> over to get added for consideration. >> >> On Tue, Sep 29, 2015 at 11:32 AM, Mark Voelker <mvoel...@vmware.com >> <mailto:mvoel...@vmware.com>> wrote: >> >> >> Mark T. Voelker >> >> >> >> > On Sep 29, 2015, at 12:36 PM, Matt Fischer <m...@mattfischer.com >> <mailto: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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-operators mailing list >> openstack-operat...@lists.openstack.org >> <mailto:openstack-operat...@lists.openstack.org> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> >> >> >> __________________________________________________________________________ >> 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 >> > > -- Sean Dague http://dague.net __________________________________________________________________________ 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
