Open Stack

On 09/29/2015 01:32 PM, Mark Voelker wrote:
> 
> Mark T. Voelker
> 
> 
> 
>> On Sep 29, 2015, at 12:36 PM, Matt Fischer <matt at 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