> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
