On Mar 3, 2014, at 1:25 PM, Vishvananda Ishaya <vishvana...@gmail.com> wrote:
> This seems like a reasonable and well thought out approach but It feels > like we are removing our ability to innovate. I know we are worried about > maintaining multiple APIs, but I’m still leaning towards putting the v3 > API out and just keeping v2 around for a long time. Yes, its a maintenance > burden, but if we aren’t adding a lot of features to v2, I don’t know if > it is really THAT bad. As an SDK developer this affects me and all other SDK developers directly. We need a guiding principle. To borrow a chestnut from Linux, “We do not break userspace!” Now DO NOT take this to mean that I’m against a v3 API. I truly understand the need to find a way forward with APIs to make them more consistent and open to innovation. Read on. You know what happens when you break a developer’s application? They start to examine their options w.r.t. where they deploy those applications. If OpenStack is going to deprecate any API I depend on and break my app, the time between now and that EOL is the perfect opportunity to research other platforms. And if they go somewhere else, there’s a good chance they’re not coming back. IMO v3 would be doable. But there would need to be commitment from the developers of OpenStack to support v2 until it can be proven that it’s no longer in use. “support”, “proven”, and “use” would all need to be defined but the point is that apps would not be broken, period. IMO v2 as proposed here would be doable. Obviously there should be no problem here. Some (probably not all) consequences to applications and SDKs of going the v3 route: 1. You need to accept that application developers (whether they’re using SDKs or not) might not switch to v3, ever. If there isn’t a compelling reason to upgrade, they likely won’t. It could be that v3 is just a bridge for OpenStack developers only to get to a v4 API that has enough compelling features for the rest of the world to upgrade. I want to draw an analogy to the whole Python 3 thing but, honestly, I’m not familiar enough with it and I think I’d be walking into a minefield around here. ;) 2. The copy/paste duplicate code that you'd have in OpenStack for v2 and v3? That’s probably going to be copy/paste duplicate code in the applications/SDKs too. More code. More bugs. More maintenance. Worse developer experience. 3. Any hope of applications/SDKs upgrading to v3 depends heavily on how well the delta is documented. It’s not enough to say that there is a v3 and have a handful of high-level bullets points saying what changed. We need an extremely fine level of detail about what has changed per parameter/method call/status code/whatever and what we should be using in v3 instead of what was in v2. Without this, upgrading is a non-starter. Some (probably not all) consequences to the SDKs of going the v2 route: 1. These likely all fall on the OpenStack services side. More difficult to innovate? Less consistent? etc. Personally, I’m pretty evenly split on which route to take. If the v3 route was taken and a commitment is made to supporting v2 indefinitely, I could get on board with that. If the v2 route was taken, it’s a no brainer. I trust that the OpenStack developers will make the call in the best interests of the application developers and operators that depend on the Nova API day in and day out. Guided by the principle that we do not break userspace. It’s a huge sign of the maturity and stability of OpenStack that this discussion is happening. Thank you, Everett _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
