Open Stack

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

	-Sean

On 02/19/2014 12:36 PM, Russell Bryant wrote:
> Greetings,
> 
> The v3 API effort has been going for a few release cycles now.  As we
> approach the Icehouse release, we are faced with the following question:
> "Is it time to mark v3 stable?"
> 
> My opinion is that I think we need to leave v3 marked as experimental
> for Icehouse.
> 
> There are a number of reasons for this:
> 
> 1) Discussions about the v2 and v3 APIs at the in-person Nova meetup
> last week made me come to the realization that v2 won't be going away
> *any* time soon.  In some cases, users have long term API support
> expectations (perhaps based on experience with EC2).  In the best case,
> we have to get all of the SDKs updated to the new API, and then get to
> the point where everyone is using a new enough version of all of these
> SDKs to use the new API.  I don't think that's going to be quick.
> 
> We really don't want to be in a situation where we're having to force
> any sort of migration to a new API.  The new API should be compelling
> enough that everyone *wants* to migrate to it.  If that's not the case,
> we haven't done our job.
> 
> 2) There's actually quite a bit still left on the existing v3 todo list.
>  We have some notes here:
> 
> https://etherpad.openstack.org/p/NovaV3APIDoneCriteria
> 
> One thing is nova-network support.  Since nova-network is still not
> deprecated, we certainly can't deprecate the v2 API without nova-network
> support in v3.  We removed it from v3 assuming nova-network would be
> deprecated in time.
> 
> Another issue is that we discussed the tasks API as the big new API
> feature we would include in v3.  Unfortunately, it's not going to be
> complete for Icehouse.  It's possible we may have some initial parts
> merged, but it's much smaller scope than what we originally envisioned.
>  Without this, I honestly worry that there's not quite enough compelling
> functionality yet to encourage a lot of people to migrate.
> 
> 3) v3 has taken a lot more time and a lot more effort than anyone
> thought.  This makes it even more important that we're not going to need
> a v4 any time soon.  Due to various things still not quite wrapped up,
> I'm just not confident enough that what we have is something we all feel
> is Nova's API of the future.
> 
> 
> Let's all take some time to reflect on what has happened with v3 so far
> and what it means for how we should move forward.  We can regroup for Juno.
> 
> Finally, I would like to thank everyone who has helped with the effort
> so far.  Many hours have been put in to code and reviews for this.  I
> would like to specifically thank Christopher Yeoh for his work here.
> Chris has done an *enormous* amount of work on this and deserves credit
> for it.  He has taken on a task much bigger than anyone anticipated.
> Thanks, Chris!
> 


-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140220/704c2c0f/attachment.pgp>