Open Stack

On Wed, 26 Feb 2014 14:50:46 -0800
Dan Smith <dms at 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