On Thu, 2014-02-20 at 08:22 -0500, Sean Dague wrote: > I agree that we shouldn't be rushing something that's not ready, but I > guess it raises kind of a meta issue. > > When we started this journey this was because v2 has a ton of warts, is > completely wonky on the code internals, which leads to plenty of bugs. > v3 was both a surface clean up, but it was also a massive internals > clean up. I think comparing servers.py:create is a good look at the > differences: > > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L768 > - v2 > > vs. > > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/servers.py#L415 > - v3 > > v3 was small on user surface changes for a reason, because the idea was > that it would be a quick cut over, the migration pain would be minimal, > and v2 could be dropped relatively quickly (2 cycles). > > However.... if the new thinking is that v2 is going to be around for a > long time then I think it raises questions about this whole approach. > Because dual maintenance is bad. We see this today where stable/* trees > end up broken in CI for weeks because no one is working on it. > > We're also duplicating a lot of test and review energy in having 2 API > stacks. Even before v3 has come out of experimental it's consumed a huge > amount of review resource on both the Nova and Tempest sides to get it > to it's current state. > > So my feeling is that in order to get more energy and focus on the API, > we need some kind of game plan to get us to a single API version, with a > single data payload in L (or on the outside, M). If the decision is v2 > must be in both those releases (and possibly beyond), then it seems like > asking other hard questions. > > * why do a v3 at all? instead do we figure out a way to be able to > evolve v2 in a backwards compatible way. > * if we aren't doing a v3, can we deprecate XML in v2 in Icehouse so > that working around all that code isn't a velocity inhibitor in the > cleanups required in v2? Because some of the crazy hacks that exist to > make XML structures work for the json in v2 is kind of special. > > This big bang approach to API development may just have run it's course, > and no longer be a useful development model. Which is good to find out. > Would have been nice to find out earlier... but not all lessons are easy > or cheap. :)
All excellent points, Sean. I would add that I personally would love to see all API extensions removed from the API eventually. I'd also love to see the use of JSON Schema and JSON-Home utilized across the API for discovery purposes. Best, -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev