Open Stack

> 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.

However, remember I've maintained that I think we can unify a lot of the
work to make using almost the same code work for multiple ways of
accessing the API. I think it's much better to structure it as multiple
views into the same data. My concern with the v2 -> v3 approach, is that
I think instead of explicitly duplicating 100% of everything and then
looking for ways to squash the two pieces back together, we should be
making calculated changes and supporting just the delta. I think that if
we did that, we'd avoid making simple naming and CamelCase changes as
I'm sure we'll try to avoid starting from v3. Why not start with v2?

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?

--Dan