+1 on the v2 on v3 proxy idea. Since none of other suggestions lead to easy decision, we might pay more attention here, especially when there are surely stackers, including myself, willing to provide solid contribution to it. Further and detailed discussion on technical feasibility, work sizing, etc. does help.<br><br>发自139邮箱mail.10086.cn<br><br>----The following is the content of the forwarded email----<br>From：Sean Dague  <sean@dague.net><br>To：openstack-dev <openstack-dev@lists.openstack.org><br>Date：2014-03-04 20:49:03<br>Subject：Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API<br><br>So this thread is getting deep again, as I expect they all will, so I'm<br>just going to top post and take the ire for doing so.<br><br>I also want to summarize what I've seen in the threads so far:<br><br>v2 needed forever - if I do a sentiment analysis here looking at the<br>orgs people are coming from, most of this is currently coming from<br>Rackspace folks (publicly). There might be many reasons for this, one of<br>which is the fact that they've done a big transition in the near past<br>(between *not openstack* and Openstack), and felt that pain.<br>Understanding that pain is good.<br><br>It is interesting that Phil actually brings up a completely different<br>issue from the HP cloud side, which is the amount of complaints they are<br>having to field about how terrible the v2 API is. HP has actually had an<br>OpenStack cloud public longer than Rackspace. So this feedback shouldn't<br>be lost.<br><br>So I feel like while some deployers have expressed no interest in moving<br>forward on API, others can't get there soon enough.<br><br>Which makes me think a lot about point 4. As has already been suggested<br>we could actually make v2 a proxy to v3. And just like with images and<br>volumes, it becomes frozen in Juno, and people that want more features<br>will move to the v3 API. Just like with other services.<br><br>This requires internal cleanups as well. However it wouldn't shut down<br>future evolution of the interface.<br><br>Nova really has 4 interfaces today<br> * Nova v2 JSON<br> * Nova v2 XML<br> * Nova v3 JSON<br> * EC2<br><br>I feel like if we had to lose one to decrease maintenance cost, Nova v2<br>XML is the one to lose. And if we did, v2 on v3 isn't the craziest thing<br>in the world. It's not free, but neither is the backport.<br><br>I also feel like the code duplication approach for v2 and v3 was taken<br>because the Glance folks had a previously bad experience on common code<br>with 2 APIs. However, their surface was small enough that the dual code<br>trees were fine. Nova is a beast in this regard.<br><br>I also feel like more folks are excited about working on the v2 on v3<br>approach, given that Kenichi is already prototyping on it. And it is<br>important to have excitement in this work as well. The human factor,<br>about the parts that people want to work on, is critical to the success<br>of Nova as a project.<br><br>This project has always been about coming up with the best ideas,<br>regardless of where they came from. So I'd like to make sure people<br>aren't making up their mind early on this, and have retreated to the<br>idea of winning this discussion. The outcome of this is important.<br>Because it basically sets up the framework of how we work on improving<br>the Nova interface... for a long time.<br><br>I also feel like the 2 complaints that come up on v3 repeatedly, that<br>it's a bunch of copy and paste, and that it doesn't implement anything<br>new, are kind of disingenuous. Because those were explicit design<br>constraints imposed and agreed on by the nova core team on the approach.<br>And if those are the complaints on the approach, why weren't those<br>brought up in advance?<br><br>At the end of the day, I'm on the fence. Because what I actually want is<br>somewhat orthogonal to all of this. Which is a real discoverable<br>interface, and substantially less optional Nova core. And I've yet to<br>figure out which approach sets us up for doing that better.<br><br>        -Sean<br><br>On 03/03/2014 12:32 PM, Russell Bryant wrote:<br>> There has been quite a bit of discussion about the future of the v3 API<br>> recently. There has been growing support for the idea that we should<br>> change course and focus on evolving the existing v2 API instead of<br>> putting out a new major revision. This message is a more complete<br>> presentation of that proposal that concludes that we can do what we<br>> really need to do with only the v2 API.<br>> <br>> Keeping only the v2 API requires some confidence that we can stick with<br>> it for years to come. We don't want to be revisiting this any time<br>> soon. This message addresses a bunch of different questions about how<br>> things would work if we only had v2.<br>> <br>> 1) What about tasks?<br>> <br>> In some cases, the proposed integration of tasks is backwards<br>> compatible. A task ID will be added to a header. The biggest point of<br>> debate was if and how we would change the response for creating a<br>> server. For tasks in v2, we would not change the response by default.<br>> The task ID would just be in a header. However, if and when the client<br>> starts exposing version support information, we can provide an<br>> alternative/preferred response based on tasks.<br>> <br>> For example:<br>> <br>> Accept: application/jsontype=task<br>> <br>> 2) Versioning extensions<br>> <br>> One of the points being addressed in the v3 API was the ability to<br>> version extensions. In v2, we have historically required new API<br>> extensions, even for changes that are backwards compatible. We propose<br>> the following:<br>> <br>> - Add a version number to v2 API extensions<br>> - Allow backwards compatible changes to these API extensions,<br>> accompanied by a version number increase<br>> - Add the option to advertise an extension as deprecated, which can be<br>> used for all those extensions created only to advertise the availability<br>> of new input parameters<br>> <br>> 3) Core versioning<br>> <br>> Another pain point in API maintenance has been having to create API<br>> extensions for every small addition to the core API. We propose that a<br>> version number be exposed for the core API that exposes the revision of<br>> the core API in use. With that in place, backwards compatible changes<br>> such as adding a new property to a resource would be allowed when<br>> accompanied by a version number increase.<br>> <br>> With versioning of the core and API extensions, we will be able to cut<br>> down significantly on the number of changes that require an API<br>> extension without sacrificing the ability of a client to discover<br>> whether the addition is present or not.<br>> <br>> 4) API Proxying<br>> <br>> We don't see proxying APIs as a problem. It is the cost we pay for<br>> choosing to split apart projects after they are released. We don't<br>> think it's fair to break users just because we have chosen to split<br>> apart the backend implementation.<br>> <br>> Further, the APIs that are proxied are frozen while those in the other<br>> projects are evolving. We believe that as more features are available<br>> only via the native APIs in Cinder, Glance, and Neutron, users will<br>> naturally migrate over to the native APIs.<br>> <br>> Over time, we can ensure clients are able to query the API without the<br>> need to proxy by adding new formats or extensions that don't return data<br>> that needed to be proxied.<br>> <br>> 5) Capitalization and Naming Consistency<br>> <br>> Some of the changes in the v3 API included changes to capitalization and<br>> naming for improved consistency. If we stick with v2 only, we will not<br>> be able to make any of these changes. However, we believe that not<br>> breaking any existing clients and not having to maintain a second API is<br>> worth not making these changes, or supporting some indirection to<br>> achieve this for newer clients if we decide it is important.<br>> <br>> 6) Response Code Consistency and Correctness<br>> <br>> The v2 API has many places where the response code returned for a given<br>> operation is not strictly correct. For example a 200 is returned when a<br>> 202 would be more appropriate. Correcting these issues should be<br>> considered for improving the future use of the API, however there does<br>> not seem to be any support for considering this a critical problem right<br>> now. There are two approaches that can be taken to improve this in v2:<br>> <br>> Just fix them. Right now, we return some codes that imply we have dealt<br>> with a request, when all we have done is queue it for processing (and<br>> vice versa). In the future, we may change the backend in such a way that<br>> a return code needs to change to continue to be accurate anyway. If we<br>> just assume that return codes may change to properly reflect the action<br>> that was taken, then we can correct existing errors and move on.<br>> Accept them as wrong but not critically so. With this approach, we can<br>> strive for correctness in the future without changing behavior of our<br>> existing APIs. Nobody seems to complain about them right now, so<br>> changing them seems to be little gain. If the client begins exposing a<br>> version header (which we need for other things) then we could<br>> alternately start returning accurate codes for those clients.<br>> <br>> The key point here is that we see a way forward with this in the v2 API<br>> regardless of which path we choose.<br>> <br>> 7) Entrypoint based extensions<br>> <br>> The v3 effort included improvements to the infrastructure used to<br>> implement the API, both for proper extensions and modular construction<br>> of the core API. We definitely want that for v2, and since these are<br>> just internal implementation details, there is no reason why we can't<br>> implement these improvements in the v2 API. Note that with the addition<br>> of versioning of extensions and the core, we should be adding fewer API<br>> extensions and may be able to collapse some that we already have.<br>> <br>> 8) Input Validation<br>> <br>> Previously, much of our input validation happened at the database driver<br>> layer for various reasons. This means that behavior of the API depends<br>> on such user-invisible things as which RDBM is in use. Thus, our input<br>> validation is already inconsistent across deployments. Further, the move<br>> to objects as the communication mechanism between the API and the<br>> backend means that more input validation is going on than we once had<br>> anyway, and this is not something we can avoid unless we freeze the<br>> backend anyway.<br>> <br>> Exposing a definition like jsonschema is something that we should do<br>> anyway, and the process of doing so should allow us to define what was<br>> previously undefined. Given the variance of the behavior depending on<br>> the database used on the backend, getting something reasonably strict<br>> should be roughly equivalent (user-wise) to working against a provider<br>> that was using something other than MySQL.<br>> <br>> 9) v3 ... if not now, when?<br>> <br>> Not in the foreseeable future. We don't see it happening unless some<br>> group of people wanted to rebuild the API from scratch in such a way<br>> that it doesn't look anything like the current API. The new API would<br>> have to be different and compelling enough that we'd be willing to<br>> maintain it along side the current API for several years.<br>> <br>> 10) Conclusion and Proposal<br>> <br>> The v3 API effort has produced a lot of excellent work. However, the<br>> majority opinion seems to be that we should avoid the cost of<br>> maintaining two APIs if at all possible. We should apply what has been<br>> learned to the existing API where we can and focus on making v2<br>> something that we can continue to maintain for years to come.<br>> <br>> We recognize and accept that it is a failure of Nova project leadership<br>> that we did not come to this conclusion much sooner. We hope to have<br>> learned from the experience to help avoiding a situation like this<br>> happening again in the future.<br>> <br>> Please provide your input on this proposal, even if it is just agreement<br>> with this as the way forward.<br>> <br>> Thanks,<br>> <br>> Proposal authors / sponsors:<br>> <br>> Russell Bryant<br>> Dan Smith<br>> John Garbutt<br>> Andrew Laski<br>> <br>> _______________________________________________<br>> OpenStack-dev mailing list<br>> OpenStack-dev@lists.openstack.org<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> <br><br><br>-- <br>Sean Dague<br>Samsung Research America<br>sean@dague.net / sean.dague@samsung.com<br>http://dague.net<br><br>