Open Stack

On Wed, 26 Feb 2014 06:29:02 -0800
Dan Smith <dms at danplanet.com> wrote:
> > So I was thinking about this and Ken'ichi has basically said pretty
> > much the same thing in his reply to this thread. I don't think it
> > makes client moves any easier though - this is all about lowering
> > our maintenance costs. 
> 
> So, in the other fork of this thread, I think you said we can't
> improve v2 because we're concerned about its incredible fragility.
> The above statement seems to imply that we can totally rewrite it as
> decorators on top of v3? I don't get that :)

So for starters we'd only do this once the V2 API is frozen. And I do
agree its carries significant. But there are ways we can reduce the risk
compared to attempting to backport into the V2 code. By taking this
approach we don't actually have to modify/remove the existing V2 code
until we know these decorators are right. Which means that people can
test it say via an experimental /v2.1 without actually losing /v2 and
tell us if we've got the corner cases that they rely upon wrong. That
is, we hopefully avoid the situation where we don't find these
incompatiblity issues when cloud providers start getting called up by
their customers complaining that apps which used to work, now
suddenly don't (and if its something their app does rarely it could
have been quite a time since the new code was deployed).

This sort of technique also keeps the v2 and v3 code separate which
reduces the complexity.

On a related matter during some of the IRC discussions the issue of AWS
supporting every version ever released was brought up and how they
manage to do this. It was suggested that for maintenance reasons what
they most likely do is only actually implement the most recent version
and just have compatibility layers to do translation. We could do
something similarly using the above technique, or as I'd prefer a proxy
service which sits in between which does V2<->V3 translation. Again
something we'd do once V2 is frozen and have a ramp time to verify that
we've got the proxy right before it actually deploys.

Incidentally the former, but the latter especially removes the
maintenance burden within Nova that you are concerned about.

Chris.