On Wed, 26 Feb 2014 06:29:02 -0800 Dan Smith <[email protected]> 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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
