On 2015-09-28 11:43 PM, John Griffith wrote: > > > On Mon, Sep 28, 2015 at 6:19 PM, Mark Voelker <mvoel...@vmware.com > <mailto:mvoel...@vmware.com>> wrote: > > FWIW, the most popular client libraries in the last user survey[1] > 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 > API: > > https://github.com/apache/libcloud/blob/trunk/libcloud/compute/drivers/openstack.py#L251 > > * jClouds appears to support only the v1 API: > > https://github.com/jclouds/jclouds/tree/jclouds-1.9.1/apis/openstack-cinder/src/main/java/org/jclouds > > * Fog also appears to only support the v1 API: > https://github.com/fog/fog/blob/master/lib/fog/openstack/volume.rb#L99 > > * php-opencloud appears to only support the v1 API: > https://php-opencloud.readthedocs.org/en/latest/services/volume/index.html > > * 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 > > https://github.com/pkgcloud/pkgcloud/tree/master/lib/pkgcloud/openstack/blockstorage > > * OpenStack.NET does appear to support v2: > > http://www.openstacknetsdk.org/docs/html/T_net_openstack_Core_Providers_IBlockStorageProvider.htm > > 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 > RightScale: > http://docs.rightscale.com/clouds/openstack/openstack_config_prereqs.html > ). 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 [2], so there’s a case to be > made that there’s been plenty of fair warning too I suppose. > > [1] > > http://superuser.openstack.org/articles/openstack-application-developers-share-insights > [2] 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 <sorri...@gmail.com > <mailto:sorri...@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 <m...@mattfischer.com > <mailto:m...@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? > >> > >> > > http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html > >> > >> On Mon, Sep 28, 2015 at 4:25 PM, Ivan Kolodyazhny <e...@e0ne.info > <mailto:e...@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 [1] is merged, Cinder API v1 is disabled in gates by > default. We've got a filed bug [2] to remove Cinder v1 API at all. > >> > >> > >> According to Deprecation Policy [3] 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. > >> > >> [1] https://review.openstack.org/194726 > >> [2] https://bugs.launchpad.net/cinder/+bug/1467589 > >> [3] > > http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html > >> > >> 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 > Nova). > > To summarize, absolutely NO to removing V1 in Mitaka, and I think > resetting the deprecation clock is the most reasonable course of action > here. >
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 _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators