So it turns out nova isn't the only OpenStack project to attempt a full API revision.
Keystone v3 - Grizzly Glance v2 - Folsom Cinder v2 - Grizzly Out of those 3, nova doesn't use any of them! (Although there are blueprints and patches up for cinder and glance v2, but they are still in review). This discussion about the nova API can easily be applied to the other projects as well. But more importantly, I don't think a 2 year deprecation cycle is enough, if it takes almost a year and a half just to get nova to use glance v2, then a two year deprecation cycle seems awfully short. best, Joe On Tue, Feb 25, 2014 at 8:52 PM, Dan Smith <d...@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. > > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
