Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

[Thomas Goirand]

On 02/20/2016 12:38 AM, Morgan Fainberg wrote:
> AS a point we are also trying to drop "versioned endpoints" as a thing
> from the catalog going forward. Please do not add a "cinderv3" or
> "volumev3" entry to the catalog. This is something that enourages adding
> for every version a new endpoint. If every service had an entry for each
> endpoint version in the catalog it rapidly balloons the size (think of,
> the ~14? services we have now, each with now three entries per "actual
> api endpoint").

I'm actually counting 20 server packages that are setting-up endpoints
and that I have packaged for Debian.

In Tokyo, we discussed moving to a *single* endpoint, instead of 3, for
each service, since only keystone itself really uses the admin endpoint,
and that there's no much point in the internal endpoint as deployments
could magically do the right thing in routing depending on the address
of the requester (like: avoiding public IPs and count traffic when a
glance image is uploaded from within the cloud).

Has anyone started implementing anything after this discussion?

Cheers,

Thomas Goirand (zigo)

P.S; +1 for *not* adding more than a single "triplet endpoint" for a
given service.


__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Thomas Goirand]

On 02/22/2016 10:22 PM, Sean McGinnis wrote:
> On Mon, Feb 22, 2016 at 12:40:48PM +0800, Thomas Goirand wrote:
>>
>> I'd vote for the extra round trip and implementation of caching whenever
>> possible. Using another endpoint is really annoying, I already have
>> specific stuff for cinder to setup both v1 and v2 endpoint, as v2
>> doesn't fully implements what's in v1. BTW, where are we with this? Can
>> I fully get rid of the v1 endpoint, or will I still experience some
>> Tempest failures?
>>
>> Thomas Goirand (zigo)
> 
> This would really surprise me as /v2 was mostly a full copy of /v1, to
> some degree. If you see anything missing please file a bug. I am not
> aware of anything myself.
> 
> /v1 would have been gone by know according to our original deprecation
> plan. We've since realized we can't ever fully get rid of it, but there
> should be no reason to still need to set it up if you have v2.

Thanks for your reply.

All I'm reporting is issues that I experienced with Liberty. Puppet guys
also told me to setup both v1 and v2 endpoints in Keystone. It's not
really clear to me why (yet), but it solved some tempest test failures
for sure.

I'll probably have another try without setting-up the v1, and see what
happens in Tempest. If I find a bug, I'll report it in Launchpad. But
don't expect this to happen late after b3 is released, as I wont have
the time for such investigation. I may though, before the final Mitaka
release.

Cheers,

Thomas Goirand (zigo)


__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Walter A. Boring IV]

On 02/20/2016 02:42 PM, Duncan Thomas wrote:



On 20 Feb 2016 00:21, "Walter A. Boring IV" > wrote:


> Not that I'm adding much to this conversation that hasn't been said 
already, but I am pro v2 API, purely because of how painful and long 
it's been to get the official OpenStack projects to adopt the v2 API 
from v1.


I think there's a slightly different argument here. We aren't taking 
away the v2 API, probably ever. Clients that are satisfied with it can 
continue to use it, as it is, forever. For clients that aren't trying 
to do anything beyond the current basics will quite possibly be happy 
with that. Consumers have no reason to change over without compelling 
value from the change - that will come from what we implement on top 
of microversions, or not. Unlike the v1 transition, we aren't trying 
to get rid of v2, just stop changing existing semantics of it.




I'm more concerned with us not getting OpenStack projects themselves to 
not use the new features/fixes we are going to make after microversions 
land.  If we force folks to use a new endpoint, then it's the same 
problem we had getting OS projects to migrate from v1 to v2.  That took 
years.   :(


Walt



__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Knight, Clinton]

On 2/22/16, 9:33 AM, "Sean McGinnis"  wrote:

>On Sun, Feb 21, 2016 at 07:59:17PM +0200, Duncan Thomas wrote:
>> 
>> So we can't get users to change endpoints, or write our libraries to
>>have
>> sensible defaults, but we're somehow going to magically get consumers
>>to do
>> the much harder job of doing version probes in their code/libraries so
>>that
>> they don't get surprised by unexpected results? This seems to be
>>entirely
>> nuts. If 'they' can't change endpoints (and we can't make the libraries
>>we
>> write just do the right thing without needing to change endpoints) then
>>how
>> are 'they' expected to do the probing magic that will be required at
>>some
>> unpredictable poin tin the future, but which you'll get away without
>>until
>> then?
>> 
>> This would also make us inconsistent with the other projects that have
>> implemented microversions - so we're changing a known working pattern,
>>to
>> try to avoid the problem of a user having to get their settings right if
>> they want new functionality, and hoping this doesn't introduce entirely
>> predictable and foreseeable bugs in the future that can't actually be
>>fixed
>> except by checking/changing every client library out there? There's no
>>way
>> that's a sensible API design.
>> 
>> 
>> --
>> Duncan Thomas
>
>I've spent the weekend thoroughly convincing myself one way or the
>other. The reality is, either one can _work_.
>
>I've asked Scott to proceed with the /v3 endpoint though. Ultimately,
>that is the safest route we can take to protect end users from
>accidentally doing something bad.
>
>A key thing here is that /v2 is not going away. So to an end user that
>doesn't know or doesn't care, things will just keep on working the way
>it has always worked and they don't need to worry.
>
>As far as the argument that some folks are still using /v1 - from my
>perspective they will need to migrate any way. So whether that is going
>to /v2 or /v3, it really won't make much of a difference there.

Ideally it would make no difference.  Like we did in Manila, you can
document for users that /v3 at the 3.0 microversion is functionally
identical to /v2.  So anyone still on /v1 can jump to /v3 with no extra
effort over /v2.

Clinton

>
>Sean (smcginnis)
>
>> 
>>_
>>_
>> 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


__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Sean McGinnis]

On Sun, Feb 21, 2016 at 07:59:17PM +0200, Duncan Thomas wrote:
> 
> So we can't get users to change endpoints, or write our libraries to have
> sensible defaults, but we're somehow going to magically get consumers to do
> the much harder job of doing version probes in their code/libraries so that
> they don't get surprised by unexpected results? This seems to be entirely
> nuts. If 'they' can't change endpoints (and we can't make the libraries we
> write just do the right thing without needing to change endpoints) then how
> are 'they' expected to do the probing magic that will be required at some
> unpredictable poin tin the future, but which you'll get away without until
> then?
> 
> This would also make us inconsistent with the other projects that have
> implemented microversions - so we're changing a known working pattern, to
> try to avoid the problem of a user having to get their settings right if
> they want new functionality, and hoping this doesn't introduce entirely
> predictable and foreseeable bugs in the future that can't actually be fixed
> except by checking/changing every client library out there? There's no way
> that's a sensible API design.
> 
> 
> --
> Duncan Thomas

I've spent the weekend thoroughly convincing myself one way or the
other. The reality is, either one can _work_.

I've asked Scott to proceed with the /v3 endpoint though. Ultimately,
that is the safest route we can take to protect end users from
accidentally doing something bad.

A key thing here is that /v2 is not going away. So to an end user that
doesn't know or doesn't care, things will just keep on working the way
it has always worked and they don't need to worry.

As far as the argument that some folks are still using /v1 - from my
perspective they will need to migrate any way. So whether that is going
to /v2 or /v3, it really won't make much of a difference there.

Sean (smcginnis)

> __
> 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] [cinder] adding a new /v3 endpoint for api-microversions

[Sean McGinnis]

On Mon, Feb 22, 2016 at 12:40:48PM +0800, Thomas Goirand wrote:
> 
> I'd vote for the extra round trip and implementation of caching whenever
> possible. Using another endpoint is really annoying, I already have
> specific stuff for cinder to setup both v1 and v2 endpoint, as v2
> doesn't fully implements what's in v1. BTW, where are we with this? Can
> I fully get rid of the v1 endpoint, or will I still experience some
> Tempest failures?
> 
> Thomas Goirand (zigo)

This would really surprise me as /v2 was mostly a full copy of /v1, to
some degree. If you see anything missing please file a bug. I am not
aware of anything myself.

/v1 would have been gone by know according to our original deprecation
plan. We've since realized we can't ever fully get rid of it, but there
should be no reason to still need to set it up if you have v2.

> 
> 
> __
> 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] [cinder] adding a new /v3 endpoint for api-microversions

[Sean Dague]

On 02/21/2016 12:59 PM, Duncan Thomas wrote:
> On 21 February 2016 at 19:34, Jay S. Bryant
> >
> wrote:
> 
> Spent some time talking to Sean about this on Friday afternoon and
> bounced back and forth between the two options.  At first, /v3 made
> the most sense to me ... at least it did at the meetup.  With people
> like Sean Dague and Morgan Fainberg weighing in with concerns, it
> seems like we should reconsider.  Duncan, your comment here about
> customers moving when they are ready is somewhat correct.  That,
> however, I am concerned is a a small subset of the users.  I think
> many users want to move but don't know any better.  That was what we
> encountered with our consumers.  They didn't understand that they
> needed to update the endpoint and couldn't figure out why their new
> functions weren't working.
> 
> So, I am leaning towards going with the /v2 endpoint and making sure
> that the clients we can control are set up properly and we put
> safety checks in the server end.  I think that may be the safest way
> to go.
> 
> 
> So we can't get users to change endpoints, or write our libraries to
> have sensible defaults, but we're somehow going to magically get
> consumers to do the much harder job of doing version probes in their
> code/libraries so that they don't get surprised by unexpected results?
> This seems to be entirely nuts. If 'they' can't change endpoints (and we
> can't make the libraries we write just do the right thing without
> needing to change endpoints) then how are 'they' expected to do the
> probing magic that will be required at some unpredictable poin tin the
> future, but which you'll get away without until then?
> 
> This would also make us inconsistent with the other projects that have
> implemented microversions - so we're changing a known working pattern,
> to try to avoid the problem of a user having to get their settings right
> if they want new functionality, and hoping this doesn't introduce
> entirely predictable and foreseeable bugs in the future that can't
> actually be fixed except by checking/changing every client library out
> there? There's no way that's a sensible API design.

Not entirely.

Nova did a seperate endpoint mostly because we actually had an entirely
duplicate wsgi stack (which was going to be v3). We needed 2 endpoints
to make sure that the base microversion was indistinguishable.

Manilla did a dedicated endpoint for philosophical reasons.

Ironic just extended the /v1 in place.

-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] [cinder] adding a new /v3 endpoint for api-microversions

[Duncan Thomas]

On 22 February 2016 at 06:40, Thomas Goirand  wrote:

>
> I'd vote for the extra round trip and implementation of caching whenever
> possible. Using another endpoint is really annoying, I already have
> specific stuff for cinder to setup both v1 and v2 endpoint, as v2
> doesn't fully implements what's in v1. BTW, where are we with this? Can
> I fully get rid of the v1 endpoint, or will I still experience some
> Tempest failures?
>


Can you detail what isn't in V2 that is in V1 please? I'm not aware of
anything, and I'd consider anything missing to be a serious bug

-- 
Duncan Thomas
__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Thomas Goirand]

On 02/18/2016 11:38 PM, D'Angelo, Scott wrote:
> Cinder team is proposing to add support for API microversions [1]. It came up 
> at our mid-cycle that we should add a new /v3 endpoint [2]. Discussions on 
> IRC have raised questions about this [3]
> 
> Please weigh in on the design decision to add a new /v3 endpoint for Cinder 
> for clients to use when they wish to have api-microversions.
> 
> PRO add new /v3 endpoint: A client should not ask for new-behaviour against 
> old /v2 endpoint, because that might hit an old pre-microversion (i.e. 
> Liberty) server, and that server might carry on with old behaviour. The 
> client would not know this without checking, and so strange things happen 
> silently.
> It is possible for client to check the response from the server, but his 
> requires an extra round trip.
> It is possible to implement some type of caching of supported 
> (micro-)version, but not all clients will do this.
> Basic argument is that  continuing to use /v2 endpoint either requires an 
> extra trip for each request (absent caching) meaning performance slow-down, 
> or possibility of unnoticed errors.
> 
> CON add new endpoint:
> Downstream cost of changing endpoints is large. It took ~3 years to move from 
> /v1 -> /v2 and we will have to support the deprecated /v2 endpoint forever.
> If we add microversions with /v2 endpoint, old scripts will keep working on 
> /v2 and they will continue to work.
> We would assume that people who choose to use microversions will check that 
> the server supports it.
> 
> Scottda

I'd vote for the extra round trip and implementation of caching whenever
possible. Using another endpoint is really annoying, I already have
specific stuff for cinder to setup both v1 and v2 endpoint, as v2
doesn't fully implements what's in v1. BTW, where are we with this? Can
I fully get rid of the v1 endpoint, or will I still experience some
Tempest failures?

Thomas Goirand (zigo)


__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Arkady_Kanevsky]

With nova and Keystone both at v3 is helps to consistent versioning across all 
projects.
Still need documentation for transition clients from one API version to next.
With new functionality not available in previous version it should be easier 
than API changes.


-Original Message-
From: Walter A. Boring IV [mailto:walter.bor...@hpe.com]
Sent: Friday, February 19, 2016 4:18 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] adding a new /v3 endpoint for 
api-microversions


>> But, there are no such clients today. And there is no library that
>> does this yet. It will be 4 - 6 months (or even more likely 12+)
>> until that's in the ecosystem. Which is why adding the header
>> validation to existing
>> v2 API, and backporting to liberty / kilo, will provide really
>> substantial coverage for the concern the bswartz is bringing forward.
> Yeah, I have to agree with that. We can certainly have the protection
> out in time.
>
> The only concern there is the admin who set up his Kilo initial
> release cloud and doesn't want to touch it for updates. But they
> likely have more pressing issues than this any way.
>
>> -Sean
>>
>>

Not that I'm adding much to this conversation that hasn't been said already, 
but I am pro v2 API, purely because of how painful and long it's been to get 
the official OpenStack projects to adopt the v2 API from v1. I know we need to 
be sort of concerned about other 'client's
that call the API, but for me that's way down the lists of concerns.
If we go to v3 API, most likely it's going to be another 3+ years before folks 
can use the new Cinder features that the microversioned changes will provides. 
This in effect invalidates the microversion capability in Cinder's API 
completely.

/sadness
Walt

__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Duncan Thomas]

On 21 February 2016 at 19:34, Jay S. Bryant 
wrote:

> Spent some time talking to Sean about this on Friday afternoon and bounced
> back and forth between the two options.  At first, /v3 made the most sense
> to me ... at least it did at the meetup.  With people like Sean Dague and
> Morgan Fainberg weighing in with concerns, it seems like we should
> reconsider.  Duncan, your comment here about customers moving when they are
> ready is somewhat correct.  That, however, I am concerned is a a small
> subset of the users.  I think many users want to move but don't know any
> better.  That was what we encountered with our consumers.  They didn't
> understand that they needed to update the endpoint and couldn't figure out
> why their new functions weren't working.
>
> So, I am leaning towards going with the /v2 endpoint and making sure that
> the clients we can control are set up properly and we put safety checks in
> the server end.  I think that may be the safest way to go.
>

So we can't get users to change endpoints, or write our libraries to have
sensible defaults, but we're somehow going to magically get consumers to do
the much harder job of doing version probes in their code/libraries so that
they don't get surprised by unexpected results? This seems to be entirely
nuts. If 'they' can't change endpoints (and we can't make the libraries we
write just do the right thing without needing to change endpoints) then how
are 'they' expected to do the probing magic that will be required at some
unpredictable poin tin the future, but which you'll get away without until
then?

This would also make us inconsistent with the other projects that have
implemented microversions - so we're changing a known working pattern, to
try to avoid the problem of a user having to get their settings right if
they want new functionality, and hoping this doesn't introduce entirely
predictable and foreseeable bugs in the future that can't actually be fixed
except by checking/changing every client library out there? There's no way
that's a sensible API design.


--
Duncan Thomas
__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Jay S. Bryant]

On 02/20/2016 04:42 PM, Duncan Thomas wrote:



On 20 Feb 2016 00:21, "Walter A. Boring IV" > wrote:


> Not that I'm adding much to this conversation that hasn't been said 
already, but I am pro v2 API, purely because of how painful and long 
it's been to get the official OpenStack projects to adopt the v2 API 
from v1.


I think there's a slightly different argument here. We aren't taking 
away the v2 API, probably ever. Clients that are satisfied with it can 
continue to use it, as it is, forever. For clients that aren't trying 
to do anything beyond the current basics will quite possibly be happy 
with that. Consumers have no reason to change over without compelling 
value from the change - that will come from what we implement on top 
of microversions, or not. Unlike the v1 transition, we aren't trying 
to get rid of v2, just stop changing existing semantics of it.




__
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
Spent some time talking to Sean about this on Friday afternoon and 
bounced back and forth between the two options.  At first, /v3 made the 
most sense to me ... at least it did at the meetup.  With people like 
Sean Dague and Morgan Fainberg weighing in with concerns, it seems like 
we should reconsider.  Duncan, your comment here about customers moving 
when they are ready is somewhat correct.  That, however, I am concerned 
is a a small subset of the users.  I think many users want to move but 
don't know any better.  That was what we encountered with our 
consumers.  They didn't understand that they needed to update the 
endpoint and couldn't figure out why their new functions weren't working.


So, I am leaning towards going with the /v2 endpoint and making sure 
that the clients we can control are set up properly and we put safety 
checks in the server end.  I think that may be the safest way to go.


Jay

__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Duncan Thomas]

On 20 Feb 2016 00:21, "Walter A. Boring IV"  wrote:

> Not that I'm adding much to this conversation that hasn't been said
already, but I am pro v2 API, purely because of how painful and long it's
been to get the official OpenStack projects to adopt the v2 API from v1.

I think there's a slightly different argument here. We aren't taking away
the v2 API, probably ever. Clients that are satisfied with it can continue
to use it, as it is, forever. For clients that aren't trying to do anything
beyond the current basics will quite possibly be happy with that. Consumers
have no reason to change over without compelling value from the change -
that will come from what we implement on top of microversions, or not.
Unlike the v1 transition, we aren't trying to get rid of v2, just stop
changing existing semantics of it.
__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Walter A. Boring IV]

But, there are no such clients today. And there is no library that does
this yet. It will be 4 - 6 months (or even more likely 12+) until that's
in the ecosystem. Which is why adding the header validation to existing
v2 API, and backporting to liberty / kilo, will provide really
substantial coverage for the concern the bswartz is bringing forward.

Yeah, I have to agree with that. We can certainly have the protection
out in time.

The only concern there is the admin who set up his Kilo initial release
cloud and doesn't want to touch it for updates. But they likely have
more pressing issues than this any way.


-Sean




Not that I'm adding much to this conversation that hasn't been said 
already, but I am pro v2 API, purely because of how painful and long 
it's been to get the official OpenStack projects to adopt the v2 API 
from v1.  I know we need to be sort of concerned about other 'client's 
that call the API, but for me that's way down the lists of concerns.   
If we go to v3 API, most likely it's going to be another 3+ years before 
folks can use the new Cinder features that the microversioned changes 
will provides.  This in effect invalidates the microversion capability 
in Cinder's API completely.


/sadness
Walt

__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Ben Swartzlander]

On 02/19/2016 11:24 AM, Sean Dague wrote:

On 02/19/2016 11:15 AM, Ben Swartzlander wrote:

On 02/19/2016 10:57 AM, Sean Dague wrote:

On 02/18/2016 10:38 AM, D'Angelo, Scott wrote:

Cinder team is proposing to add support for API microversions [1]. It
came up at our mid-cycle that we should add a new /v3 endpoint [2].
Discussions on IRC have raised questions about this [3]

Please weigh in on the design decision to add a new /v3 endpoint for
Cinder for clients to use when they wish to have api-microversions.

PRO add new /v3 endpoint: A client should not ask for new-behaviour
against old /v2 endpoint, because that might hit an old
pre-microversion (i.e. Liberty) server, and that server might carry
on with old behaviour. The client would not know this without
checking, and so strange things happen silently.
It is possible for client to check the response from the server, but
his requires an extra round trip.
It is possible to implement some type of caching of supported
(micro-)version, but not all clients will do this.
Basic argument is that  continuing to use /v2 endpoint either
requires an extra trip for each request (absent caching) meaning
performance slow-down, or possibility of unnoticed errors.

CON add new endpoint:
Downstream cost of changing endpoints is large. It took ~3 years to
move from /v1 -> /v2 and we will have to support the deprecated /v2
endpoint forever.
If we add microversions with /v2 endpoint, old scripts will keep
working on /v2 and they will continue to work.
We would assume that people who choose to use microversions will
check that the server supports it.


The concern as I understand it is that by extending the v2 API with
microversions the following failure scenario exists

If:

1) a client already is using the /v2 API
2) a client opt's into using microversions on /v2
3) that client issues a request on a Cinder API v2 endpoint without
microversion support
4) that client fails check if micoversions are supported by a GET of /v2
or by checking the return of the OpenStack-API-Version return header


It disagree that this (step 4) is a failure. Clients should not have to
do a check at all. The client should tell the server what it wants to do
(send the request and version) and the server should do exactly that if
and only if it can. Any requirement that the client check the server's
version is a massive violation of good API design and will cause either
performance problems or correctness problems or both.


That is a fair concern. However the Cinder API today doesn't do strict
input validation (in my understanding). Which means it's never given
users that guaruntee. Adding ?foo=bar to random resources, or extra
headers, it likely to just get silently dropped.

Strict input validation is a good thing to do, and would make a very
sensible initial microversion to get onto that path.

So this isn't really worse than the current situation. And the upside is
easier adoption.


I'm not okay with shipping a broken design just because adoption will be 
easier.


I agree the current situation could be better, but let's not let a bad 
status quo give us an excuse to build a bad future. I'm also in favor of 
input validation. Arguably it was harder to do in the past because we 
didn't have a clear versioning mechanism and we needed to to give 
ourselves a way to make backwards-compatible changes to APIs. With a 
proper versioning scheme, input validation is very practical, and the 
only hurdle to getting it implemented is the amount of work.


-Ben



-Sean




__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Sean McGinnis]

On Fri, Feb 19, 2016 at 11:28:09AM -0500, Sean Dague wrote:
> On 02/19/2016 11:20 AM, Sean McGinnis wrote:
> > On Fri, Feb 19, 2016 at 10:57:38AM -0500, Sean Dague wrote:
> >> The concern as I understand it is that by extending the v2 API with
> >> microversions the following failure scenario exists
> >>
> >> If:
> >>
> >> 1) a client already is using the /v2 API
> >> 2) a client opt's into using microversions on /v2
> >> 3) that client issues a request on a Cinder API v2 endpoint without
> >> microversion support
> >> 4) that client fails check if micoversions are supported by a GET of /v2
> >> or by checking the return of the OpenStack-API-Version return header
> >> 5) that client issues a request against a resource on /v2 with
> >> parameters that would create a radically different situation that would
> >> be hard to figure out later.
> >>
> >> And, only if all these things happen is there a concern.
> > 
> > I think it's actually even simpler than that. And possibly therefore
> > more likely to actually happen in the wild.
> > 
> > 1) a client already is using microversions
> 
> But, there are no such clients today. And there is no library that does
> this yet. It will be 4 - 6 months (or even more likely 12+) until that's
> in the ecosystem. Which is why adding the header validation to existing
> v2 API, and backporting to liberty / kilo, will provide really
> substantial coverage for the concern the bswartz is bringing forward.

Yeah, I have to agree with that. We can certainly have the protection
out in time.

The only concern there is the admin who set up his Kilo initial release
cloud and doesn't want to touch it for updates. But they likely have
more pressing issues than this any way.

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

__
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] [cinder] adding a new /v3 endpoint for api-microversions

[Morgan Fainberg]

On Fri, Feb 19, 2016 at 8:24 AM, Sean Dague  wrote:

> On 02/19/2016 11:15 AM, Ben Swartzlander wrote:
> > On 02/19/2016 10:57 AM, Sean Dague wrote:
> >> On 02/18/2016 10:38 AM, D'Angelo, Scott wrote:
> >>> Cinder team is proposing to add support for API microversions [1]. It
> >>> came up at our mid-cycle that we should add a new /v3 endpoint [2].
> >>> Discussions on IRC have raised questions about this [3]
> >>>
> >>> Please weigh in on the design decision to add a new /v3 endpoint for
> >>> Cinder for clients to use when they wish to have api-microversions.
> >>>
> >>> PRO add new /v3 endpoint: A client should not ask for new-behaviour
> >>> against old /v2 endpoint, because that might hit an old
> >>> pre-microversion (i.e. Liberty) server, and that server might carry
> >>> on with old behaviour. The client would not know this without
> >>> checking, and so strange things happen silently.
> >>> It is possible for client to check the response from the server, but
> >>> his requires an extra round trip.
> >>> It is possible to implement some type of caching of supported
> >>> (micro-)version, but not all clients will do this.
> >>> Basic argument is that  continuing to use /v2 endpoint either
> >>> requires an extra trip for each request (absent caching) meaning
> >>> performance slow-down, or possibility of unnoticed errors.
> >>>
> >>> CON add new endpoint:
> >>> Downstream cost of changing endpoints is large. It took ~3 years to
> >>> move from /v1 -> /v2 and we will have to support the deprecated /v2
> >>> endpoint forever.
> >>> If we add microversions with /v2 endpoint, old scripts will keep
> >>> working on /v2 and they will continue to work.
> >>> We would assume that people who choose to use microversions will
> >>> check that the server supports it.
> >>
> >> The concern as I understand it is that by extending the v2 API with
> >> microversions the following failure scenario exists
> >>
> >> If:
> >>
> >> 1) a client already is using the /v2 API
> >> 2) a client opt's into using microversions on /v2
> >> 3) that client issues a request on a Cinder API v2 endpoint without
> >> microversion support
> >> 4) that client fails check if micoversions are supported by a GET of /v2
> >> or by checking the return of the OpenStack-API-Version return header
> >
> > It disagree that this (step 4) is a failure. Clients should not have to
> > do a check at all. The client should tell the server what it wants to do
> > (send the request and version) and the server should do exactly that if
> > and only if it can. Any requirement that the client check the server's
> > version is a massive violation of good API design and will cause either
> > performance problems or correctness problems or both.
>
> That is a fair concern. However the Cinder API today doesn't do strict
> input validation (in my understanding). Which means it's never given
> users that guaruntee. Adding ?foo=bar to random resources, or extra
> headers, it likely to just get silently dropped.
>
> Strict input validation is a good thing to do, and would make a very
> sensible initial microversion to get onto that path.
>
> So this isn't really worse than the current situation. And the upside is
> easier adoption.
>
> -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
>

AS a point we are also trying to drop "versioned endpoints" as a thing from
the catalog going forward. Please do not add a "cinderv3" or "volumev3"
entry to the catalog. This is something that enourages adding for every
version a new endpoint. If every service had an entry for each endpoint
version in the catalog it rapidly balloons the size (think of, the ~14?
services we have now, each with now three entries per "actual api
endpoint"). The catalog is good to a point, but if everyone added a
versioned endpoint it would rapidly become more of a beast that it is and
potentially become a bigger bottleneck/performance issue than it already is.

Asking the endpoint a single time what versions it supports and relevant
information not encoded in the catalog (lets be fair, the catlog does not
contain everything, heck, you don't even know what version of v2 cinder API
an endpoint has, you should probably ask for discoverability to provide
good responses to the user vs random/spurious 404 because a new
cinderclient knows extra APIs than the juno cinder API provides).

I think Sean is giving good guidance on extending from /v2 personally. I
have other mixed feelings on microversions (see the nova thread on
indicating compatibility), but if microversions are to be supported, it
isn't terrible to extend from your existing point as long as the client is
expected to get "current" behavior 

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

[Sean Dague]

On 02/19/2016 11:20 AM, Sean McGinnis wrote:
> On Fri, Feb 19, 2016 at 10:57:38AM -0500, Sean Dague wrote:
>> The concern as I understand it is that by extending the v2 API with
>> microversions the following failure scenario exists
>>
>> If:
>>
>> 1) a client already is using the /v2 API
>> 2) a client opt's into using microversions on /v2
>> 3) that client issues a request on a Cinder API v2 endpoint without
>> microversion support
>> 4) that client fails check if micoversions are supported by a GET of /v2
>> or by checking the return of the OpenStack-API-Version return header
>> 5) that client issues a request against a resource on /v2 with
>> parameters that would create a radically different situation that would
>> be hard to figure out later.
>>
>> And, only if all these things happen is there a concern.
> 
> I think it's actually even simpler than that. And possibly therefore
> more likely to actually happen in the wild.
> 
> 1) a client already is using microversions

But, there are no such clients today. And there is no library that does
this yet. It will be 4 - 6 months (or even more likely 12+) until that's
in the ecosystem. Which is why adding the header validation to existing
v2 API, and backporting to liberty / kilo, will provide really
substantial coverage for the concern the bswartz is bringing forward.

-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] [cinder] adding a new /v3 endpoint for api-microversions

[Sean Dague]

On 02/19/2016 11:15 AM, Ben Swartzlander wrote:
> On 02/19/2016 10:57 AM, Sean Dague wrote:
>> On 02/18/2016 10:38 AM, D'Angelo, Scott wrote:
>>> Cinder team is proposing to add support for API microversions [1]. It
>>> came up at our mid-cycle that we should add a new /v3 endpoint [2].
>>> Discussions on IRC have raised questions about this [3]
>>>
>>> Please weigh in on the design decision to add a new /v3 endpoint for
>>> Cinder for clients to use when they wish to have api-microversions.
>>>
>>> PRO add new /v3 endpoint: A client should not ask for new-behaviour
>>> against old /v2 endpoint, because that might hit an old
>>> pre-microversion (i.e. Liberty) server, and that server might carry
>>> on with old behaviour. The client would not know this without
>>> checking, and so strange things happen silently.
>>> It is possible for client to check the response from the server, but
>>> his requires an extra round trip.
>>> It is possible to implement some type of caching of supported
>>> (micro-)version, but not all clients will do this.
>>> Basic argument is that  continuing to use /v2 endpoint either
>>> requires an extra trip for each request (absent caching) meaning
>>> performance slow-down, or possibility of unnoticed errors.
>>>
>>> CON add new endpoint:
>>> Downstream cost of changing endpoints is large. It took ~3 years to
>>> move from /v1 -> /v2 and we will have to support the deprecated /v2
>>> endpoint forever.
>>> If we add microversions with /v2 endpoint, old scripts will keep
>>> working on /v2 and they will continue to work.
>>> We would assume that people who choose to use microversions will
>>> check that the server supports it.
>>
>> The concern as I understand it is that by extending the v2 API with
>> microversions the following failure scenario exists
>>
>> If:
>>
>> 1) a client already is using the /v2 API
>> 2) a client opt's into using microversions on /v2
>> 3) that client issues a request on a Cinder API v2 endpoint without
>> microversion support
>> 4) that client fails check if micoversions are supported by a GET of /v2
>> or by checking the return of the OpenStack-API-Version return header
> 
> It disagree that this (step 4) is a failure. Clients should not have to
> do a check at all. The client should tell the server what it wants to do
> (send the request and version) and the server should do exactly that if
> and only if it can. Any requirement that the client check the server's
> version is a massive violation of good API design and will cause either
> performance problems or correctness problems or both.

That is a fair concern. However the Cinder API today doesn't do strict
input validation (in my understanding). Which means it's never given
users that guaruntee. Adding ?foo=bar to random resources, or extra
headers, it likely to just get silently dropped.

Strict input validation is a good thing to do, and would make a very
sensible initial microversion to get onto that path.

So this isn't really worse than the current situation. And the upside is
easier adoption.

-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] [cinder] adding a new /v3 endpoint for api-microversions

[Sean McGinnis]

On Fri, Feb 19, 2016 at 10:57:38AM -0500, Sean Dague wrote:
> The concern as I understand it is that by extending the v2 API with
> microversions the following failure scenario exists
> 
> If:
> 
> 1) a client already is using the /v2 API
> 2) a client opt's into using microversions on /v2
> 3) that client issues a request on a Cinder API v2 endpoint without
> microversion support
> 4) that client fails check if micoversions are supported by a GET of /v2
> or by checking the return of the OpenStack-API-Version return header
> 5) that client issues a request against a resource on /v2 with
> parameters that would create a radically different situation that would
> be hard to figure out later.
> 
> And, only if all these things happen is there a concern.

I think it's actually even simpler than that. And possibly therefore
more likely to actually happen in the wild.

1) a client already is using microversions
2) that client issues a request to a non-microversion release without
   first doing a check for microversion support
3) the request is serviced as best the non-microversion service knows
   how
4) the client checks the response to validate the microversion header
   and too late realizes it wasn't supported and a slightly different
   action was performed than what they expected

> 
> So let's look at each one.
> 
> 1) clients already using /v2 API
> 
> Last cycle when we tried to drop v1 from devstack we got a bunch of
> explosions. In researching it it was determined that very little
> supported cinder v2 -
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/075760.html
> 
> 
> At that point not even OpenStack Client itself, or Rally. And definitely
> no libraries except python cinderclient. So the entire space of #1 is
> python cinderclient, or non open rest clients.
> 
> 2 & 4) are coupled. A good client that does 2 should do 4, and not only
> depend on the 406 failure. cinderclient definitely should be made to do
> that. Which means we are completely left with only custom non open
> access code that's a concern. That's definitely still a concern, but
> again the problem space is smaller.
> 
> 3) can be mitigated if cinder backports patches to stable branches to
> throw the 406 when sending the header. It's mitigation. Code already is
> out in the wild, however it does help. And given other security fixes
> people will probably take these patches into production.

This is one thing I was thinking about. But even if we do, there is no
guarantee that older releases will have been updated.

On the other hand, microversion adoption probably isn't going to take
off immediately. You are correct that there are still many clients using
v1. If it's taken folks this long to get to v2, the chances of a
wholesale migration to microversions is pretty low. Chances are by the
time it is prevalent, this will no longer be an issue.

> 
> 5) is there an example where this is expected? or is this theoretical.

Good point. At this point it is theoretical.

> 
> 
> My very high concern is the fact that v2 adoption remains quite low, and
> that a v3 will hurt that even further. Especially as it means a whole
> other endpoint... "volumev2" was already a big problem in teaching a
> bunch of software that it needs a new type, "volumev3" is something I
> don't think anyone wants to see. I'd really like to see more of these
> improvements get out there.
> 
> At the end of the day, this is the call of the Cinder team.
> 
> However, I've seen real 3rd party vendor software hitting the Nova API
> that completely bypasses the service catalog, and hits /v2.1 directly
> (it's not using microversions). Which means that it can't work on a Kilo
> cloud. For actually no reason. As /v2.1 and /v2 are semantically
> equivalent. Vendors do weird things. They read the docs, say "oh this is
> the latest API" and only implement to that. They don't need any new
> features, don't realize the time delay in these things getting out
> there. It's a big regret that we have multiple endpoints because it
> means these kinds of applications basically break for no good reason.

This is a bit of a circular argument in my opinion. We don't expect them
to pay attention enough to the difference between /v2 and /v3 (or the
lack of a difference), yet we expect them to pay attention enough to
know to check for microversion support before making an API call.

I'm really not arguing for one way or the other here. I really
appreciate the input. Just trying to think through implications and see
what makes the most sense.

The one thing that makes me slightly lean towards a new endpoint is that
it is risky to expect consumers of the API to pay enough attention to know
to do these checks. A /v3 endpoint would be the safest route to protect
against folks doing something stupid.

> 
> So my recommendation is to extend out from the /v2 endpoint. This is
> conceptually what you are actually doing. The base microversion will be
> v2 API as it exists 

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

[Ben Swartzlander]

On 02/19/2016 10:57 AM, Sean Dague wrote:

On 02/18/2016 10:38 AM, D'Angelo, Scott wrote:

Cinder team is proposing to add support for API microversions [1]. It came up 
at our mid-cycle that we should add a new /v3 endpoint [2]. Discussions on IRC 
have raised questions about this [3]

Please weigh in on the design decision to add a new /v3 endpoint for Cinder for 
clients to use when they wish to have api-microversions.

PRO add new /v3 endpoint: A client should not ask for new-behaviour against old 
/v2 endpoint, because that might hit an old pre-microversion (i.e. Liberty) 
server, and that server might carry on with old behaviour. The client would not 
know this without checking, and so strange things happen silently.
It is possible for client to check the response from the server, but his 
requires an extra round trip.
It is possible to implement some type of caching of supported (micro-)version, 
but not all clients will do this.
Basic argument is that  continuing to use /v2 endpoint either requires an extra 
trip for each request (absent caching) meaning performance slow-down, or 
possibility of unnoticed errors.

CON add new endpoint:
Downstream cost of changing endpoints is large. It took ~3 years to move from /v1 
-> /v2 and we will have to support the deprecated /v2 endpoint forever.
If we add microversions with /v2 endpoint, old scripts will keep working on /v2 
and they will continue to work.
We would assume that people who choose to use microversions will check that the 
server supports it.


The concern as I understand it is that by extending the v2 API with
microversions the following failure scenario exists

If:

1) a client already is using the /v2 API
2) a client opt's into using microversions on /v2
3) that client issues a request on a Cinder API v2 endpoint without
microversion support
4) that client fails check if micoversions are supported by a GET of /v2
or by checking the return of the OpenStack-API-Version return header


It disagree that this (step 4) is a failure. Clients should not have to 
do a check at all. The client should tell the server what it wants to do 
(send the request and version) and the server should do exactly that if 
and only if it can. Any requirement that the client check the server's 
version is a massive violation of good API design and will cause either 
performance problems or correctness problems or both.


-Ben Swartzlander


5) that client issues a request against a resource on /v2 with
parameters that would create a radically different situation that would
be hard to figure out later.

And, only if all these things happen is there a concern.

So let's look at each one.

1) clients already using /v2 API

Last cycle when we tried to drop v1 from devstack we got a bunch of
explosions. In researching it it was determined that very little
supported cinder v2 -
http://lists.openstack.org/pipermail/openstack-dev/2015-September/075760.html


At that point not even OpenStack Client itself, or Rally. And definitely
no libraries except python cinderclient. So the entire space of #1 is
python cinderclient, or non open rest clients.

2 & 4) are coupled. A good client that does 2 should do 4, and not only
depend on the 406 failure. cinderclient definitely should be made to do
that. Which means we are completely left with only custom non open
access code that's a concern. That's definitely still a concern, but
again the problem space is smaller.

3) can be mitigated if cinder backports patches to stable branches to
throw the 406 when sending the header. It's mitigation. Code already is
out in the wild, however it does help. And given other security fixes
people will probably take these patches into production.

5) is there an example where this is expected? or is this theoretical.


My very high concern is the fact that v2 adoption remains quite low, and
that a v3 will hurt that even further. Especially as it means a whole
other endpoint... "volumev2" was already a big problem in teaching a
bunch of software that it needs a new type, "volumev3" is something I
don't think anyone wants to see. I'd really like to see more of these
improvements get out there.

At the end of the day, this is the call of the Cinder team.

However, I've seen real 3rd party vendor software hitting the Nova API
that completely bypasses the service catalog, and hits /v2.1 directly
(it's not using microversions). Which means that it can't work on a Kilo
cloud. For actually no reason. As /v2.1 and /v2 are semantically
equivalent. Vendors do weird things. They read the docs, say "oh this is
the latest API" and only implement to that. They don't need any new
features, don't realize the time delay in these things getting out
there. It's a big regret that we have multiple endpoints because it
means these kinds of applications basically break for no good reason.

So my recommendation is to extend out from the /v2 endpoint. This is
conceptually what you are actually doing. The base microversion 

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

[Sean Dague]

On 02/18/2016 10:38 AM, D'Angelo, Scott wrote:
> Cinder team is proposing to add support for API microversions [1]. It came up 
> at our mid-cycle that we should add a new /v3 endpoint [2]. Discussions on 
> IRC have raised questions about this [3]
> 
> Please weigh in on the design decision to add a new /v3 endpoint for Cinder 
> for clients to use when they wish to have api-microversions.
> 
> PRO add new /v3 endpoint: A client should not ask for new-behaviour against 
> old /v2 endpoint, because that might hit an old pre-microversion (i.e. 
> Liberty) server, and that server might carry on with old behaviour. The 
> client would not know this without checking, and so strange things happen 
> silently.
> It is possible for client to check the response from the server, but his 
> requires an extra round trip.
> It is possible to implement some type of caching of supported 
> (micro-)version, but not all clients will do this.
> Basic argument is that  continuing to use /v2 endpoint either requires an 
> extra trip for each request (absent caching) meaning performance slow-down, 
> or possibility of unnoticed errors.
> 
> CON add new endpoint:
> Downstream cost of changing endpoints is large. It took ~3 years to move from 
> /v1 -> /v2 and we will have to support the deprecated /v2 endpoint forever.
> If we add microversions with /v2 endpoint, old scripts will keep working on 
> /v2 and they will continue to work.
> We would assume that people who choose to use microversions will check that 
> the server supports it.

The concern as I understand it is that by extending the v2 API with
microversions the following failure scenario exists

If:

1) a client already is using the /v2 API
2) a client opt's into using microversions on /v2
3) that client issues a request on a Cinder API v2 endpoint without
microversion support
4) that client fails check if micoversions are supported by a GET of /v2
or by checking the return of the OpenStack-API-Version return header
5) that client issues a request against a resource on /v2 with
parameters that would create a radically different situation that would
be hard to figure out later.

And, only if all these things happen is there a concern.

So let's look at each one.

1) clients already using /v2 API

Last cycle when we tried to drop v1 from devstack we got a bunch of
explosions. In researching it it was determined that very little
supported cinder v2 -
http://lists.openstack.org/pipermail/openstack-dev/2015-September/075760.html


At that point not even OpenStack Client itself, or Rally. And definitely
no libraries except python cinderclient. So the entire space of #1 is
python cinderclient, or non open rest clients.

2 & 4) are coupled. A good client that does 2 should do 4, and not only
depend on the 406 failure. cinderclient definitely should be made to do
that. Which means we are completely left with only custom non open
access code that's a concern. That's definitely still a concern, but
again the problem space is smaller.

3) can be mitigated if cinder backports patches to stable branches to
throw the 406 when sending the header. It's mitigation. Code already is
out in the wild, however it does help. And given other security fixes
people will probably take these patches into production.

5) is there an example where this is expected? or is this theoretical.


My very high concern is the fact that v2 adoption remains quite low, and
that a v3 will hurt that even further. Especially as it means a whole
other endpoint... "volumev2" was already a big problem in teaching a
bunch of software that it needs a new type, "volumev3" is something I
don't think anyone wants to see. I'd really like to see more of these
improvements get out there.

At the end of the day, this is the call of the Cinder team.

However, I've seen real 3rd party vendor software hitting the Nova API
that completely bypasses the service catalog, and hits /v2.1 directly
(it's not using microversions). Which means that it can't work on a Kilo
cloud. For actually no reason. As /v2.1 and /v2 are semantically
equivalent. Vendors do weird things. They read the docs, say "oh this is
the latest API" and only implement to that. They don't need any new
features, don't realize the time delay in these things getting out
there. It's a big regret that we have multiple endpoints because it
means these kinds of applications basically break for no good reason.

So my recommendation is to extend out from the /v2 endpoint. This is
conceptually what you are actually doing. The base microversion will be
v2 API as it exists today, and you are negotiating up from there.

-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] [cinder] adding a new /v3 endpoint for api-microversions

[Sean McGinnis]

On Thu, Feb 18, 2016 at 03:38:39PM +, D'Angelo, Scott wrote:
> Cinder team is proposing to add support for API microversions [1]. It came up 
> at our mid-cycle that we should add a new /v3 endpoint [2]. Discussions on 
> IRC have raised questions about this [3]
> 
> Please weigh in on the design decision to add a new /v3 endpoint for Cinder 
> for clients to use when they wish to have api-microversions.
> 
> PRO add new /v3 endpoint: A client should not ask for new-behaviour against 
> old /v2 endpoint, because that might hit an old pre-microversion (i.e. 
> Liberty) server, and that server might carry on with old behaviour. The 
> client would not know this without checking, and so strange things happen 
> silently.

The concern here is that not only could "strange things happen
silently". Even if the client is checking the response for reported
microversion support, by the time it realizes it's talking to a server
that does not understand microversions, the request could have caused
something to happen that it can't easily recover from.

> It is possible for client to check the response from the server, but his 
> requires an extra round trip.
> It is possible to implement some type of caching of supported 
> (micro-)version, but not all clients will do this.
> Basic argument is that  continuing to use /v2 endpoint either requires an 
> extra trip for each request (absent caching) meaning performance slow-down, 
> or possibility of unnoticed errors.
> 
> CON add new endpoint:
> Downstream cost of changing endpoints is large. It took ~3 years to move from 
> /v1 -> /v2 and we will have to support the deprecated /v2 endpoint forever.
> If we add microversions with /v2 endpoint, old scripts will keep working on 
> /v2 and they will continue to work.
> We would assume that people who choose to use microversions will check that 
> the server supports it.
> 
> Scottda
> 
> [1] https://etherpad.openstack.org/p/cinder-api-microversions
> [2] https://www.youtube.com/watch?v=tfEidbzPOCc around 1:20
> [3] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-cinder/%23openstack-cinder.2016-02-18.log.html
>   around 13:17
> 
> 
> 
> __
> 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