Open Stack

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 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev