Sean, openstack client supports Cinder API v2 since Liberty. What it the right way ti fix grenade?
Regards, Ivan Kolodyazhny, Web Developer On Wed, Sep 30, 2015 at 1:32 PM, Sean Dague <s...@dague.net> wrote: > On 09/29/2015 01:32 PM, Mark Voelker wrote: > > > > 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 > > I would agree that the amount of breaks even in our own system has been > substantial here, and I'm personally feeling we should probably revert > the devstack change that turns off v1. It looks like it wasn't just one > client that got caught in this, but most of them. > > This feels like this transition has been too much stick, and not enough > carrot. IIRC openstack client wouldn't work with cinder v2 until a > couple of months ago, as that made me do some weird things in grenade in > building volumes. [1] > > -Sean > > 1. > > https://github.com/openstack-dev/grenade/blob/master/projects/70_cinder/resources.sh#L40-L41 > > -- > 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