Open Stack

On Tue, 25 Feb 2014 20:52:14 -0800
Dan Smith <dms at danplanet.com> wrote:

> > This would reduce the amount of duplication which is required (I
> > doubt we could remove all duplication though) and whether its worth
> > it for say the rescue example is debatable. But for those cases
> > you'd only need to make the modification in one file.
> 
> Don't forget the cases where the call chain changes -- where we end up
> calling into conductor instead of compute, or changing how we fetch
> complicated information (like BDMs) that we end up needing to send to
> something complicated like the run_instance call. As we try to evolve
> compute/api.py to do different things, the changes we have to drive
> into the api/openstack/ code will continue.

Sure, but won't most of those continue to be abstracted away by this
new common layer? Its not like the rework will expect any new data in
the request, or ultimately any new data returned in the request
(because these would all involve API changes).

> We've already established that we can get a version from the client on
> an incoming request, so why wouldn't we start with v2 and evolve the
> important pieces instead of explicitly making the decision to break
> everyone by moving to v3 and *then* start with that practice?

Because the V2 API code is really fragile which we want to keep stable.
And the cost of breaking it is high as we probably won't catch many
cases in the gate or review and we'll end up breaking clients when
providers deploy it. And so doing a backport is a huge amount of work
with a large amount of risk attached and compared to starting afresh
with the V3 work we'd be making infrastructure changes to a live, moving
target.

It's the same sorts of reasons that library developers on occasion
decide to release a new major version which knowingly are not backwards
compatible. Even if it means some sort of dual support for a period.

Chris