On Tue, 25 Feb 2014 20:52:14 -0800 Dan Smith <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
