<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 29, 2015 at 6:48 AM, Ivan Kolodyazhny <span dir="ltr"><<a href="mailto:e0ne@e0ne.info" target="_blank">e0ne@e0ne.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">First of all, I would like to say thank you for the feedback!<div><br></div><div>TBH, I did'n propose to remove API v1 at all in Mitaka. I was against to remove v1 API instead of disabling it.</div></div></blockquote><div> </div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Sorry Ivan, I did not mean to imply that you were proposing removal. You did ask the question so I answered :) </div></div><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div><div class="gmail_extra"><br clear="all"><div><div>Regards,<br>Ivan Kolodyazhny</div></div><div><div class="h5">
<br><div class="gmail_quote">On Tue, Sep 29, 2015 at 2:37 PM, Gorka Eguileor <span dir="ltr"><<a href="mailto:geguileo@redhat.com" target="_blank">geguileo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 28/09, John Griffith wrote:<br>
> On Mon, Sep 28, 2015 at 6:19 PM, Mark Voelker <<a href="mailto:mvoelker@vmware.com" target="_blank">mvoelker@vmware.com</a>> wrote:<br>
><br>
> > FWIW, the most popular client libraries in the last user survey[1] other<br>
> > than OpenStack’s own clients were: libcloud (48 respondents), jClouds (36<br>
> > respondents), Fog (34 respondents), php-opencloud (21 respondents),<br>
> > DeltaCloud (which has been retired by Apache and hasn’t seen a commit in<br>
> > two years, but 17 respondents are still using it), pkgcloud (15<br>
> > respondents), and OpenStack.NET (14 respondents). Of those:<br>
> ><br>
> > * libcloud appears to support the nova-volume API but not the cinder API:<br>
> > <a href="https://github.com/apache/libcloud/blob/trunk/libcloud/compute/drivers/openstack.py#L251" rel="noreferrer" target="_blank">https://github.com/apache/libcloud/blob/trunk/libcloud/compute/drivers/openstack.py#L251</a><br>
> ><br>
> > * jClouds appears to support only the v1 API:<br>
> > <a href="https://github.com/jclouds/jclouds/tree/jclouds-1.9.1/apis/openstack-cinder/src/main/java/org/jclouds" rel="noreferrer" target="_blank">https://github.com/jclouds/jclouds/tree/jclouds-1.9.1/apis/openstack-cinder/src/main/java/org/jclouds</a><br>
> ><br>
> > * Fog also appears to only support the v1 API:<br>
> > <a href="https://github.com/fog/fog/blob/master/lib/fog/openstack/volume.rb#L99" rel="noreferrer" target="_blank">https://github.com/fog/fog/blob/master/lib/fog/openstack/volume.rb#L99</a><br>
> ><br>
> > * php-opencloud appears to only support the v1 API:<br>
> > <a href="https://php-opencloud.readthedocs.org/en/latest/services/volume/index.html" rel="noreferrer" target="_blank">https://php-opencloud.readthedocs.org/en/latest/services/volume/index.html</a><br>
> ><br>
> > * DeltaCloud I honestly haven’t looked at since it’s thoroughly dead, but<br>
> > I can’t imagine it supports v2.<br>
> ><br>
> > * pkgcloud has beta-level support for Cinder but I think it’s v1 (may be<br>
> > mistaken): <a href="https://github.com/pkgcloud/pkgcloud/#block-storage----beta" rel="noreferrer" target="_blank">https://github.com/pkgcloud/pkgcloud/#block-storage----beta</a><br>
> > and<br>
> > <a href="https://github.com/pkgcloud/pkgcloud/tree/master/lib/pkgcloud/openstack/blockstorage" rel="noreferrer" target="_blank">https://github.com/pkgcloud/pkgcloud/tree/master/lib/pkgcloud/openstack/blockstorage</a><br>
> ><br>
> > * OpenStack.NET does appear to support v2:<br>
> > <a href="http://www.openstacknetsdk.org/docs/html/T_net_openstack_Core_Providers_IBlockStorageProvider.htm" rel="noreferrer" target="_blank">http://www.openstacknetsdk.org/docs/html/T_net_openstack_Core_Providers_IBlockStorageProvider.htm</a><br>
> ><br>
> > Now, it’s anyone’s guess as to whether or not users of those client<br>
> > libraries actually try to use them for volume operations or not<br>
> > (anecdotally I know a few clouds I help support are using client libraries<br>
> > that only support v1), and some users might well be using more than one<br>
> > library or mixing in code they wrote themselves. But most of the above<br>
> > that support cinder do seem to rely on v1. Some management tools also<br>
> > appear to still rely on the v1 API (such as RightScale:<br>
> > <a href="http://docs.rightscale.com/clouds/openstack/openstack_config_prereqs.html" rel="noreferrer" target="_blank">http://docs.rightscale.com/clouds/openstack/openstack_config_prereqs.html</a><br>
> > ). From that perspective it might be useful to keep it around a while<br>
> > longer and disable it by default. Personally I’d probably lean that way,<br>
> > especially given that folks here on the ops list are still reporting<br>
> > problems too.<br>
> ><br>
> > That said, v1 has been deprecated since Juno, and the Juno release notes<br>
> > said it was going to be removed [2], so there’s a case to be made that<br>
> > there’s been plenty of fair warning too I suppose.<br>
> ><br>
> > [1]<br>
> > <a href="http://superuser.openstack.org/articles/openstack-application-developers-share-insights" rel="noreferrer" target="_blank">http://superuser.openstack.org/articles/openstack-application-developers-share-insights</a><br>
> > [2] <a href="https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_7" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_7</a><br>
> ><br>
> > At Your Service,<br>
> ><br>
> > Mark T. Voelker<br>
> ><br>
> ><br>
> ><br>
> > > On Sep 28, 2015, at 7:17 PM, Sam Morrison <<a href="mailto:sorrison@gmail.com" target="_blank">sorrison@gmail.com</a>> wrote:<br>
> > ><br>
> > > Yeah we’re still using v1 as the clients that are packaged with most<br>
> > distros don’t support v2 easily.<br>
> > ><br>
> > > Eg. with Ubuntu Trusty they have version 1.1.1, I just updated our<br>
> > “volume” endpoint to point to v2 (we have a volumev2 endpoint too) and the<br>
> > client breaks.<br>
> > ><br>
> > > $ cinder list<br>
> > > ERROR: OpenStack Block Storage API version is set to 1 but you are<br>
> > accessing a 2 endpoint. Change its value through --os-volume-api-version or<br>
> > env[OS_VOLUME_API_VERSION].<br>
> > ><br>
> > > Sam<br>
> > ><br>
> > ><br>
> > >> On 29 Sep 2015, at 8:34 am, Matt Fischer <<a href="mailto:matt@mattfischer.com" target="_blank">matt@mattfischer.com</a>> wrote:<br>
> > >><br>
> > >> Yes, people are probably still using it. Last time I tried to use V2 it<br>
> > didn't work because the clients were broken, and then it went back on the<br>
> > bottom of my to do list. Is this mess fixed?<br>
> > >><br>
> > >><br>
> > <a href="http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html</a><br>
> > >><br>
> > >> On Mon, Sep 28, 2015 at 4:25 PM, Ivan Kolodyazhny <<a href="mailto:e0ne@e0ne.info" target="_blank">e0ne@e0ne.info</a>><br>
> > wrote:<br>
> > >> Hi all,<br>
> > >><br>
> > >> As you may know, we've got 2 APIs in Cinder: v1 and v2. Cinder v2 API<br>
> > was introduced in Grizzly and v1 API is deprecated since Juno.<br>
> > >><br>
> > >> After [1] is merged, Cinder API v1 is disabled in gates by default.<br>
> > We've got a filed bug [2] to remove Cinder v1 API at all.<br>
> > >><br>
> > >><br>
> > >> According to Deprecation Policy [3] looks like we are OK to remote it.<br>
> > But I would like to ask Cinder API users if any still use API v1.<br>
> > >> Should we remove it at all Mitaka release or just disable by default in<br>
> > the cinder.conf?<br>
> > >><br>
> > >> AFAIR, only Rally doesn't support API v2 now and I'm going to implement<br>
> > it asap.<br>
> > >><br>
> > >> [1] <a href="https://review.openstack.org/194726" rel="noreferrer" target="_blank">https://review.openstack.org/194726</a><br>
> > >> [2] <a href="https://bugs.launchpad.net/cinder/+bug/1467589" rel="noreferrer" target="_blank">https://bugs.launchpad.net/cinder/+bug/1467589</a><br>
> > >> [3]<br>
> > <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html</a><br>
> > >><br>
> > >> Regards,<br>
> > >> Ivan Kolodyazhny<br>
> > >><br>
> > >> _______________________________________________<br>
> > >> OpenStack-operators mailing list<br>
> > >> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
> > >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
> > >><br>
> > >><br>
> > >> _______________________________________________<br>
> > >> OpenStack-operators mailing list<br>
> > >> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
> > >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
> > ><br>
> > ><br>
> > __________________________________________________________________________<br>
> > > OpenStack Development Mailing List (not for usage questions)<br>
> > > Unsubscribe:<br>
> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> My opinion is that even though V1 has technically been deprecated for<br>
> multiple cycles, V2 was never really viable until the Liberty release.<br>
> Between issues with V2 and other components, and then the version discovery<br>
> issues that broke some things; I think we should reset the deprecation<br>
> clock so to speak.<br>
><br>
> It was only in the last milestone of Liberty that folks finally got<br>
> everything updated and talking V2. Not to mention the patch to switch the<br>
> default in devstack just landed (where everything uses it including Nova).<br>
><br>
> To summarize, absolutely NO to removing V1 in Mitaka, and I think resetting<br>
> the deprecation clock is the most reasonable course of action here.<br>
><br>
> Thanks,<br>
> John<br>
<br>
</div></div>I agree with John, regardless of the fact that the deprecation period<br>
has expired I think it would be safer to keep it a little longer.<br>
<br>
One possibility is to leave it as it is for Mitaka and for N disable it<br>
by default in cinder.conf like Ivan suggests.<br>
<br>
Cheers,<br>
Gorka.<br>
<div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>