Sean, Thanks for bringing this topic to TC meeting.
Regards, Ivan Kolodyazhny, Web Developer, http://blog.e0ne.info/, http://notacash.com/, http://kharkivpy.org.ua/ On Thu, Oct 1, 2015 at 1:43 PM, Sean Dague <s...@dague.net> wrote: > 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 >
__________________________________________________________________________ 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
