On Tue, 25 Feb 2014 10:37:14 +0000 John Garbutt <j...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev