I think disabling it by default in early M should help shake out any remaining issues - we can decide if we actually release that way later.
I'm against actually removing the V1 code however On 29 Sep 2015 15:56, "Ivan Kolodyazhny" <[email protected]> wrote: > First of all, I would like to say thank you for the feedback! > > TBH, I did'n propose to remove API v1 at all in Mitaka. I was against to > remove v1 API instead of disabling it. > > IMO, if we'll decide to leave it as is in Mitaka and disable in N release > - nothing will change. Everybody will use v1 API until N. Disabling v1 > early in Mitaka will give everybody more time to fix their clients. Anyway, > I leave a very easy way to re-enable v1. > > Regards, > Ivan Kolodyazhny > > On Tue, Sep 29, 2015 at 2:37 PM, Gorka Eguileor <[email protected]> > wrote: > >> On 28/09, John Griffith wrote: >> > On Mon, Sep 28, 2015 at 6:19 PM, Mark Voelker <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> > > 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 >> > > >> >> > > >> _______________________________________________ >> > > >> OpenStack-operators mailing list >> > > >> [email protected] >> > > >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> > > >> >> > > >> >> > > >> _______________________________________________ >> > > >> OpenStack-operators mailing list >> > > >> [email protected] >> > > >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> > > > >> > > > >> > > >> __________________________________________________________________________ >> > > > OpenStack Development Mailing List (not for usage questions) >> > > > Unsubscribe: >> > > [email protected]?subject:unsubscribe >> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >> > > >> __________________________________________________________________________ >> > > OpenStack Development Mailing List (not for usage questions) >> > > Unsubscribe: >> [email protected]?subject:unsubscribe >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >> > >> > 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. >> > >> > Thanks, >> > John >> >> I agree with John, regardless of the fact that the deprecation period >> has expired I think it would be safer to keep it a little longer. >> >> One possibility is to leave it as it is for Mitaka and for N disable it >> by default in cinder.conf like Ivan suggests. >> >> Cheers, >> Gorka. >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
