Open Stack

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 <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.
>
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev