[Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1
mgagne at internap.com
Tue Sep 29 16:31:42 UTC 2015
On 2015-09-28 11:43 PM, John Griffith wrote:
> On Mon, Sep 28, 2015 at 6:19 PM, Mark Voelker <mvoelker at vmware.com
> <mailto:mvoelker at vmware.com>> wrote:
> FWIW, the most popular client libraries in the last user survey
> other than OpenStack’s own clients were: libcloud (48 respondents),
> jClouds (36 respondents), Fog (34 respondents), php-opencloud (21
> respondents), DeltaCloud (which has been retired by Apache and
> hasn’t seen a commit in two years, but 17 respondents are still
> using it), pkgcloud (15 respondents), and OpenStack.NET (14
> respondents). Of those:
> * libcloud appears to support the nova-volume API but not the cinder
> * jClouds appears to support only the v1 API:
> * Fog also appears to only support the v1 API:
> * php-opencloud appears to only support the v1 API:
> * DeltaCloud I honestly haven’t looked at since it’s thoroughly
> dead, but I can’t imagine it supports v2.
> * pkgcloud has beta-level support for Cinder but I think it’s v1
> (may be mistaken):
> https://github.com/pkgcloud/pkgcloud/#block-storage----beta and
> * OpenStack.NET does appear to support v2:
> Now, it’s anyone’s guess as to whether or not users of those client
> libraries actually try to use them for volume operations or not
> (anecdotally I know a few clouds I help support are using client
> libraries that only support v1), and some users might well be using
> more than one library or mixing in code they wrote themselves. But
> most of the above that support cinder do seem to rely on v1. Some
> management tools also appear to still rely on the v1 API (such as
> ). From that perspective it might be useful to keep it around a
> while longer and disable it by default. Personally I’d probably
> lean that way, especially given that folks here on the ops list are
> still reporting problems too.
> That said, v1 has been deprecated since Juno, and the Juno release
> notes said it was going to be removed , so there’s a case to be
> made that there’s been plenty of fair warning too I suppose.
>  https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_7
> At Your Service,
> Mark T. Voelker
> > On Sep 28, 2015, at 7:17 PM, Sam Morrison <sorrison at gmail.com
> <mailto:sorrison at gmail.com>> wrote:
> > Yeah we’re still using v1 as the clients that are packaged with
> most distros don’t support v2 easily.
> > Eg. with Ubuntu Trusty they have version 1.1.1, I just updated our
> “volume” endpoint to point to v2 (we have a volumev2 endpoint too)
> and the client breaks.
> > $ cinder list
> > ERROR: OpenStack Block Storage API version is set to 1 but you are
> accessing a 2 endpoint. Change its value through
> --os-volume-api-version or env[OS_VOLUME_API_VERSION].
> > Sam
> >> On 29 Sep 2015, at 8:34 am, Matt Fischer <matt at mattfischer.com
> <mailto:matt at mattfischer.com>> wrote:
> >> Yes, people are probably still using it. Last time I tried to use
> V2 it didn't work because the clients were broken, and then it went
> back on the bottom of my to do list. Is this mess fixed?
> >> On Mon, Sep 28, 2015 at 4:25 PM, Ivan Kolodyazhny <e0ne at e0ne.info
> <mailto:e0ne at e0ne.info>> wrote:
> >> Hi all,
> >> As you may know, we've got 2 APIs in Cinder: v1 and v2. Cinder v2
> API was introduced in Grizzly and v1 API is deprecated since Juno.
> >> After  is merged, Cinder API v1 is disabled in gates by
> default. We've got a filed bug  to remove Cinder v1 API at all.
> >> According to Deprecation Policy  looks like we are OK to
> remote it. But I would like to ask Cinder API users if any still use
> API v1.
> >> Should we remove it at all Mitaka release or just disable by
> default in the cinder.conf?
> >> AFAIR, only Rally doesn't support API v2 now and I'm going to
> implement it asap.
> >>  https://review.openstack.org/194726
> >>  https://bugs.launchpad.net/cinder/+bug/1467589
> >> 
> >> Regards,
> >> Ivan Kolodyazhny
> My opinion is that even though V1 has technically been deprecated for
> multiple cycles, V2 was never really viable until the Liberty release.
> Between issues with V2 and other components, and then the version
> discovery issues that broke some things; I think we should reset the
> deprecation clock so to speak.
> It was only in the last milestone of Liberty that folks finally got
> everything updated and talking V2. Not to mention the patch to switch
> the default in devstack just landed (where everything uses it including
> To summarize, absolutely NO to removing V1 in Mitaka, and I think
> resetting the deprecation clock is the most reasonable course of action
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.
More information about the OpenStack-operators