Open Stack

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