[openstack-dev] [nova] Future of the Nova API

Christopher Yeoh cbkyeoh at gmail.com
Wed Feb 26 11:25:53 UTC 2014


On Tue, 25 Feb 2014 22:15:42 -0800
Joe Gordon <joe.gordon0 at gmail.com> wrote:

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

So if the warning messages are to be believed it looks like Keystone v2
is deprecated in Icehouse and possibly removed completely in K. So I
guess we'll have to do something about moving to Keystone v3 soon
(which is perhaps the point of the deprecation announcement).

I also had a quick look through the other projects and whilst we don't
have to do what everyone else does it doesn't look like any of them have
attempted to embed both the newer and older versions in the same class.
But instead done a pretty clean split between the two (though
sometimes leaving the two versions in the same file.

cinder extensions seem to be the exception where there is only set of
them - not sure if that means they are only for one version or there
are simply no API changes for them with the API version bump.

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

So if any cinder/glance/keystone people are reading this I'd be
interested to find out if they have any deprecation plans and if in
retrospect they regret not attempting to try to evolve a new major
version of their API code within the existing one.

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




More information about the OpenStack-dev mailing list