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

[Sean Dague]

Just to follow up, there was a discussion at the TC meeting on this, and
given how close we are to summit we're proposing we have a cross project
session there about it - http://odsreg.openstack.org/cfp/details/27

We'll try to get that scheduled in a way that it will not conflict with
operator sessions, so we can operators in the room for it as well.

For folks that can't make it to summit, don't worry, we'll take that
discussion as a seed and bring the results back to the list / gerrit.

On 10/01/2015 11:05 AM, Ivan Kolodyazhny wrote:
> Sean,
> 
> Thanks for bringing this topic to TC meeting.
> 
> Regards,
> Ivan Kolodyazhny,
> Web Developer,
> http://blog.e0ne.info/,
> http://notacash.com/,
> http://kharkivpy.org.ua/
> 
> On Thu, Oct 1, 2015 at 1:43 PM, Sean Dague  > wrote:
> 
> This is now queued up for discussion this week -
> https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda
> 
> On 10/01/2015 06:22 AM, Sean Dague wrote:
> > Some of us are actively watching the thread / participating. I'll make
> > sure it gets on the TC agenda in the near future.
> >
> > I think most of the recommendations are quite good, especially on the
> > client support front for clients / tools within our community.
> >
> > On 09/30/2015 10:37 PM, Matt Fischer wrote:
> >> 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
> mailto:mvoel...@vmware.com>
> >> >> wrote:
> >>
> >>
> >> Mark T. Voelker
> >>
> >>
> >>
> >> > On Sep 29, 2015, at 12:36 PM, Matt Fischer
> mailto:m...@mattfischer.com>
> >> >>
> 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
> Cinde

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

[Ivan Kolodyazhny]

Sean,

Thanks for bringing this topic to TC meeting.

Regards,
Ivan Kolodyazhny,
Web Developer,
http://blog.e0ne.info/,
http://notacash.com/,
http://kharkivpy.org.ua/

On Thu, Oct 1, 2015 at 1:43 PM, Sean Dague  wrote:

> This is now queued up for discussion this week -
> https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda
>
> On 10/01/2015 06:22 AM, Sean Dague wrote:
> > Some of us are actively watching the thread / participating. I'll make
> > sure it gets on the TC agenda in the near future.
> >
> > I think most of the recommendations are quite good, especially on the
> > client support front for clients / tools within our community.
> >
> > On 09/30/2015 10:37 PM, Matt Fischer wrote:
> >> 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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> ___
> >> OpenStack-operators mailing list
> >> openstack-operat...@lists.openstack.org
> >> 

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

[Sean Dague]

This is now queued up for discussion this week -
https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda

On 10/01/2015 06:22 AM, Sean Dague wrote:
> Some of us are actively watching the thread / participating. I'll make
> sure it gets on the TC agenda in the near future.
> 
> I think most of the recommendations are quite good, especially on the
> client support front for clients / tools within our community.
> 
> On 09/30/2015 10:37 PM, Matt Fischer wrote:
>> 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-operat...@lists.openstack.org
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>
>> __
>> 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
>>
> 
> 


-- 
Sean Dague
http

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

[Sean Dague]

Some of us are actively watching the thread / participating. I'll make
sure it gets on the TC agenda in the near future.

I think most of the recommendations are quite good, especially on the
client support front for clients / tools within our community.

On 09/30/2015 10:37 PM, Matt Fischer wrote:
> 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-operat...@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 
> 
> 
> __
> 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
> 


-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Openstack-operators] [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-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
__
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

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

[Daniel P. Berrange]

On Wed, Sep 30, 2015 at 08:10:43AM -0400, Sean Dague wrote:
> On 09/30/2015 07:29 AM, Ivan Kolodyazhny wrote:
> > Sean,
> > 
> > openstack client supports Cinder API v2 since Liberty. What it the right
> > way ti fix grenade?
> 
> Here's the thing.
> 
> With this change: Rally doesn't work, novaclient doesn't work, grenade
> doesn't work. Apparently nearly all the libraries in the real world
> don't work.
> 
> I feel like that list of incompatibilities should have been collected
> before this change. Managing a major API transition is a big deal, and
> having a pretty good idea who you are going to break before you do it is
> important. Just putting it out there and watching fallout isn't the
> right approach.

I have to agree, breaking APIs is a very big deal for consumers of
those APIs. When you break API you are trading off less work for
maintainers, vs extra pain for users. IMHO intentionally creating
pain for users is something that should be avoided unless there is
no practical alternative. I'd go as far as to say we should never
break API at all, which would mean keeping v1 around forever,
albeit recommending people use v2. If we really do want to kill
v1 and inflict pain on consumers, then we need to ensure that pain
is as close to zero as possible. This means we should not kill v1
until we've verified that all known current clients impl of v1 have
a v2 implementation available.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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

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

[Sean Dague]

On 09/30/2015 07:29 AM, Ivan Kolodyazhny wrote:
> Sean,
> 
> openstack client supports Cinder API v2 since Liberty. What it the right
> way ti fix grenade?

Here's the thing.

With this change: Rally doesn't work, novaclient doesn't work, grenade
doesn't work. Apparently nearly all the libraries in the real world
don't work.

I feel like that list of incompatibilities should have been collected
before this change. Managing a major API transition is a big deal, and
having a pretty good idea who you are going to break before you do it is
important. Just putting it out there and watching fallout isn't the
right approach.

-Sean

-- 
Sean Dague
http://dague.net

__
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

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

[Ivan Kolodyazhny]

Sean,

openstack client supports Cinder API v2 since Liberty. What it the right
way ti fix grenade?

Regards,
Ivan Kolodyazhny,
Web Developer

On Wed, Sep 30, 2015 at 1:32 PM, Sean Dague  wrote:

> On 09/29/2015 01:32 PM, 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
>
> I would agree that the amount of breaks even in our own system has been
> substantial here, and I'm personally feeling we should probably revert
> the devstack change that turns off v1. It looks like it wasn't just one
> client that got caught in this, but most of them.
>
> This feels like this transition has been too much stick, and not enough
> carrot. IIRC openstack client wouldn't work with cinder v2 until a
> couple of months ago, as that made me do some weird things in grenade in
> building volumes. [1]
>
> -Sean
>
> 1.
>
> https://github.com/openstack-dev/grenade/blob/master/projects/70_cinder/resources.sh#L40-L41
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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 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

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

[Sean Dague]

On 09/29/2015 01:32 PM, 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

I would agree that the amount of breaks even in our own system has been
substantial here, and I'm personally feeling we should probably revert
the devstack change that turns off v1. It looks like it wasn't just one
client that got caught in this, but most of them.

This feels like this transition has been too much stick, and not enough
carrot. IIRC openstack client wouldn't work with cinder v2 until a
couple of months ago, as that made me do some weird things in grenade in
building volumes. [1]

-Sean

1.
https://github.com/openstack-dev/grenade/blob/master/projects/70_cinder/resources.sh#L40-L41

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [Openstack-operators] [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 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

Re: [openstack-dev] [Openstack-operators] [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 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

Re: [openstack-dev] [Openstack-operators] [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 doesn't support API v2 now and I'm going to
> implement it asap.
> >>
> 

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

[Duncan Thomas]

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"  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 
> wrote:
>
>> On 28/09, 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-operato

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

[John Griffith]

On Tue, Sep 29, 2015 at 6:48 AM, Ivan Kolodyazhny  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 
> wrote:
>
>> On 28/09, 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

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

[Ivan Kolodyazhny]

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

> On 28/09, 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

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

[Gorka Eguileor]

On 28/09, 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 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
>

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

[John Griffith]

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

Re: [openstack-dev] [Openstack-operators] [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-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> __
> OpenStack Developmen

Re: [openstack-dev] [Openstack-operators] [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-operat...@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> 
> 
> 
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> 
__
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

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

[Matt Fischer]

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