On Wed, 26 Feb 2014 14:50:46 -0800 Dan Smith <d...@danplanet.com> wrote: > > I disagree. If the client declares support for it, I think we can very > reasonably return new stuff. > > If we take what we have today in v2 and call that 2, then we could > make novaclient send this header: > > Accept: application/json;version=2 > > Then, we have a common method in the api code called > get_client_version(req), which returns 2 if it's missing, otherwise it > returns the version the client declared. > > When we want to return something new, we do so only if > get_client_version(req) >= 3. I think that if we did that, we could > support tasks in v2, properly, today.
So I think once we start returning different response codes, or completely different structures (such as the tasks change will be), it doesn't matter if we make the change in effect by invoking /v2 prefix or /v3 prefix or we look for a header. Its a major api revision. I don't think we should pretend otherwise. The fact that clients have /v2 or /v3 hard coded is pretty much a result of a failure on our part in the first place. The nova endpoint examples for v2 should never have included the v2 prefix. And we should always have been using a form of version discovery instead. > When we come along and decide that the API should really be organized > totally differently than it is today, such that a total rewrite makes > sense, we can do that and call it v3. However, for the level of change > that we've currently done in v3, I think the above would work just > fine and avoid the churn. So doing the proposed backport of code to v2 is a huge amount of churn also. A lot of the cost of the v3 churn is already paid. I think in this thread we've discussed quite a few possible alternatives, some of which I think would significantly reduce the dual maintenance concerns on nova internals side (eg having a common layer that both v2 and v3 call into when doing non trivial calls into nova internals). But none of those alternatives seem to be acceptable, only the backport. I think the backporting approach is a substantial amount of work, which pretty much duplicates a lot of effort which has already been done. It comparatively has a higher level of risk involved and leaves us in the long term with a code base we don't want (multiple versions mixed into the same method). So just who would be willing to step up to commit to actually doing the work on this multi cycle effort? Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
