Open Stack

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[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 <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?
>     >>
>     >>
>     http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html
>     >>
>     >> 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 [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