[openstack-dev] [Openstack-operators] [cinder] [all] The future of Cinder API v1
sean at dague.net
Thu Oct 1 10:43:14 UTC 2015
This is now queued up for discussion this week -
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 <mvoelker at vmware.com
>> <mailto:mvoelker at vmware.com>> wrote:
>> Mark T. Voelker
>> > On Sep 29, 2015, at 12:36 PM, Matt Fischer <matt at mattfischer.com
>> <mailto: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
>> > 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
>> > 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  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
>> * 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  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).
>>  https://review.openstack.org/#/c/207467/
>> At Your Service,
>> Mark T. Voelker
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> <mailto:OpenStack-operators at lists.openstack.org>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev