Open Stack

On Tue, Sep 29, 2015 at 6:48 AM, Ivan Kolodyazhny <e0ne at e0ne.info> 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.
>

​Sorry Ivan, I did not mean to imply that you were proposing removal.  You
did ask the question so I answered :)


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 <geguileo at redhat.com>
> wrote:
>
>> On 28/09, John Griffith wrote:
>> > On Mon, Sep 28, 2015 at 6:19 PM, Mark Voelker <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>
>> 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>
>> 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>
>> > > 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
>> > > >> OpenStack-operators at lists.openstack.org
>> > > >>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> > > >>
>> > > >>
>> > > >> _______________________________________________
>> > > >> OpenStack-operators mailing list
>> > > >> OpenStack-operators at lists.openstack.org
>> > > >>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> > > >
>> > > >
>> > >
>> __________________________________________________________________________
>> > > > OpenStack Development Mailing List (not for usage questions)
>> > > > Unsubscribe:
>> > > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > >
>> > >
>> __________________________________________________________________________
>> > > OpenStack Development Mailing List (not for usage questions)
>> > > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?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:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150929/1ecc1af1/attachment.html>