Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

[Matt Fischer]

Thanks for summarizing this Mark. What's the best way to get feedback about
this to the TC? I'd love to see some of the items which I think are common
sense for anyone who can't just blow away devstack and start over to get
added for consideration.

On Tue, Sep 29, 2015 at 11:32 AM, Mark Voelker  wrote:

>
> Mark T. Voelker
>
>
>
> > On Sep 29, 2015, at 12:36 PM, Matt Fischer  wrote:
> >
> >
> >
> > 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
> >
> >
> > I don't think it's too much to ask that versions can't be deprecated
> until the new version is 100% working, passing all tests, and the clients
> (at least python-xxxclients) can handle it without issues. Ideally I'd like
> to also throw in the criteria that devstack, rally, tempest, and other
> services are all using and exercising the new API.
> >
> > I agree that things feel rushed.
>
>
> FWIW, the TC recently created an assert:follows-standard-deprecation tag.
> Ivan linked to a thread in which Thierry asked for input on it, but FYI the
> final language as it was approved last week [1] is a bit different than
> originally proposed.  It now requires one release plus 3 linear months of
> deprecated-but-still-present-in-the-tree as a minimum, and recommends at
> least two full stable releases for significant features (an entire API
> version would undoubtedly fall into that bucket).  It also requires that a
> migration path will be documented.  However to Matt’s point, it doesn’t
> contain any language that says specific things like:
>
> In the case of major API version deprecation:
> * $oldversion and $newversion must both work with
> [cinder|nova|whatever]client and openstackclient during the deprecation
> period.
> * It must be possible to run $oldversion and $newversion concurrently on
> the servers to ensure end users don’t have to switch overnight.
> * Devstack uses $newversion by default.
> * $newversion works in Tempest/Rally/whatever else.
>
> What it *does* do is require that a thread be started here on
> openstack-operators [2] so that operators can provide feedback.  I would
> hope that feedback like “I can’t get clients to use it so please don’t
> remove it yet” would be taken into account by projects, which seems to be
> exactly what’s happening in this case with Cinder v1.  =)
>
> I’d hazard a guess that the TC would be interested in hearing about
> whether you think that plan is a reasonable one (and given that TC election
> season is upon us, candidates for the TC probably would too).
>
> [1] https://review.openstack.org/#/c/207467/
> [2]
> http://git.openstack.org/cgit/openstack/governance/tree/reference/tags/assert_follows-standard-deprecation.rst#n59
>
> At Your Service,
>
> Mark T. Voelker
>
>
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

[Matt Fischer]

>
>
>
> 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
>


I don't think it's too much to ask that versions can't be deprecated until
the new version is 100% working, passing all tests, and the clients (at
least python-xxxclients) can handle it without issues. Ideally I'd like to
also throw in the criteria that devstack, rally, tempest, and other
services are all using and exercising the new API.

I agree that things feel rushed.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

[Mathieu Gagné]

On 2015-09-28 11:43 PM, John Griffith wrote:
> 
> 
> On Mon, Sep 28, 2015 at 6:19 PM, Mark Voelker  > 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-storagebeta 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  > 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  > 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  > 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 

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

[Mark Voelker]

Mark T. Voelker



> On Sep 29, 2015, at 12:36 PM, Matt Fischer  wrote:
> 
> 
> 
> 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
> 
> 
> I don't think it's too much to ask that versions can't be deprecated until 
> the new version is 100% working, passing all tests, and the clients (at least 
> python-xxxclients) can handle it without issues. Ideally I'd like to also 
> throw in the criteria that devstack, rally, tempest, and other services are 
> all using and exercising the new API.
> 
> I agree that things feel rushed.


FWIW, the TC recently created an assert:follows-standard-deprecation tag.  Ivan 
linked to a thread in which Thierry asked for input on it, but FYI the final 
language as it was approved last week [1] is a bit different than originally 
proposed.  It now requires one release plus 3 linear months of 
deprecated-but-still-present-in-the-tree as a minimum, and recommends at least 
two full stable releases for significant features (an entire API version would 
undoubtedly fall into that bucket).  It also requires that a migration path 
will be documented.  However to Matt’s point, it doesn’t contain any language 
that says specific things like:

In the case of major API version deprecation:
* $oldversion and $newversion must both work with [cinder|nova|whatever]client 
and openstackclient during the deprecation period.
* It must be possible to run $oldversion and $newversion concurrently on the 
servers to ensure end users don’t have to switch overnight. 
* Devstack uses $newversion by default.
* $newversion works in Tempest/Rally/whatever else.

What it *does* do is require that a thread be started here on 
openstack-operators [2] so that operators can provide feedback.  I would hope 
that feedback like “I can’t get clients to use it so please don’t remove it 
yet” would be taken into account by projects, which seems to be exactly what’s 
happening in this case with Cinder v1.  =)

I’d hazard a guess that the TC would be interested in hearing about whether you 
think that plan is a reasonable one (and given that TC election season is upon 
us, candidates for the TC probably would too).

[1] https://review.openstack.org/#/c/207467/
[2] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/tags/assert_follows-standard-deprecation.rst#n59

At Your Service,

Mark T. Voelker


>  
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

[Ivan Kolodyazhny]

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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

[Sam Morrison]

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  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  > 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@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> 
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> 
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

[Mark Voelker]

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-storagebeta 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  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  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  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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
>