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

Christopher Yeoh cbkyeoh at gmail.com
Wed Feb 26 04:44:55 UTC 2014


On Tue, 25 Feb 2014 10:37:14 +0000
John Garbutt <john at johngarbutt.com> wrote:
> 
> Now I am tempted to say we morph the V3 code to also produce the V2
> responses. And change the v3 API, so thats easier to do, and easier
> for clients to move (like don't change URLs unless we really have to).
> I know the risk for screwing that up is enormous, but maybe that makes
> the most sense?

So I was thinking about this and Ken'ichi has basically said pretty
much the same thing in his reply to this thread. I don't think it
makes client moves any easier though - this is all about lowering our
maintenance costs. 

So for the V3 API where the json/schema input validation patches have
merged, for static input validation (ie not things like does this
server exist) its all done in the decorator now, outside of actual
method. This makes the v3 API code much cleaner.

So I was pondering if its possible to write a decorator for v3 (not
json schema because we have to do some crazy stuff) that does the
equivalent of V2 input validation. Getting it right for perfectly good
input would not be that hard. But getting all the quirks of V2 just
right would be very tricky and error prone, with no tests.

Mind you, that's not a lot different from porting v3 back to v2 either.
There's also significant risk of accidentally changing the v2 API in a
way we don't intend.

But regardless I think its only something that would be feasible to
attempt once V2 is frozen. And only worth considering if the the
deprecation period for V2 is very long >2 years.

I think we do really need to get a better quantitative grip on what this
dual maintenance burden actually is. I don't think its too hard 
to measure the gate/check impact (more VMs please!) but in terms of
developer and review time overhead what do we think it will be and what
is acceptable and what isn't?

Because that needs to be somehow balanced against how long (hand wave)
that we'll have to keep dual support for and the developer cost and
review time to do any backport work. Plus throw in what sort of code
base we end up with in the end.

Chris



More information about the OpenStack-dev mailing list