<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 4, 2014 at 11:10 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">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.<br>
<br>
</div><snip> :-)<br>
<br>
Since this proposal was posted, it is clear that there is not much<br>
support for it, much less consensus. That's progress because it now<br>
seems clear to me that the path proposed (keep only v2) isn't the right<br>
answer.<br>
<br>
Let's reflect a bit on some of the other progress that I think has been<br>
made:<br>
<br>
1) Greater understanding and documentation of the v3 API effort<br>
<br>
It has led to a larger group of people taking a much closer look at what<br>
has been done with the v3 API so far. That has widened the net for<br>
feedback on what else should be done before we could call it done.<br>
<br>
Chris has put together an excellent page with the most comprehensive<br>
overview of the v3 API effort that I've seen. I think this is very helpful:<br>
<br>
<a href="http://ozlabs.org/~cyeoh/V3_API.html" target="_blank">http://ozlabs.org/~cyeoh/V3_API.html</a><br>
<br></blockquote><div><br></div><div>I still sense that the struggle with Compute v3 is the lack of documentation for contributor developers but also especially end users so that we could get feedback early and often. </div>
<div><br></div><div>My original understanding, passed by word-of-mouth, was that the goal for v3 was to define an expanded core that nearly all deployers could confidently put into production to serve their users needs. Since there's no end-user-sympathetic documentation, we learned a bit too much about how it's made, that supposedly it's implemented with "all extensions" -- a revelation that I'd still prefer to be protected from. :) Or possibly I don't understand. But the thing is, as a user advocate I shouldn't need to know that. I should know what it does and what benefits it holds.</div>
<div><br></div><div>I recently had to write a paragraph about v3 for the Operations Guide, and it was really difficult to write because of the conversational nature of the discussion. Worse still, it was difficult to tell a deployer where their voice could be best heard. I went with "respond on the user survey." I still sense we need to ensure we have data from users (deployers and end users) and that won't be available until May. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2) Expansion on ideas to ease long term support of APIs<br>
<br>
Thinking through this has led to a lot of deep thought about what<br>
changes we can make to support an API for a longer period of time.<br>
These are all ideas that can be applied to v3:<br>
<br>
- minor-versions for the core API and what changes would be<br>
considered acceptable under that scheme<br>
<br>
- how we can make significant changes that normally are not<br>
backwards compatible optional so that clients can declare<br>
support for them, easing the possible future need for another<br>
major API revision.<br>
<br>
3) New ideas to ease keeping both v2 and v3<br>
<br>
There has been some excellent input from those that have been working on<br>
the v3 API with some new ideas for how we can lessen the burden of<br>
keeping both APIs long term. I'm personally especially interested in<br>
the "v2.1" approach where v2 turns into code that transforms requests<br>
and responses to/from v3 format. More on that here:<br>
<br>
<a href="http://ozlabs.org/~cyeoh/V3_API.html#v2_v3_dual_maintenance" target="_blank">http://ozlabs.org/~cyeoh/V3_API.html#v2_v3_dual_maintenance</a><br>
<br>
<br>
What I'd like to do next is work through a new proposal that includes<br>
keeping both v2 and v3, but with a new added focus of minimizing the<br>
cost. This should include a path away from the dual code bases and to<br>
something like the "v2.1" proposal.<br></blockquote><div><br></div><div><div><br class="">I'd like to make a better API and I think details about this proposal helps us with that goal. </div><div><br></div>
<div>I'd like the effort to continue but I'd like an additional focus during the Icehouse timeframe to write end user and SDK dev docs and to listen to the user survey respondents.</div><div> </div><div>Thanks Russell and Chris for the mega-efforts here. It matters and you're fighting the good fight.</div>
<div>Anne</div><div><br></div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thank you all for your participation on this topic. It has been quite<br>
controversial, but the API we expose to our users is a really big deal.<br>
I'm feeling more and more confident that we're coming through this with<br>
a much better understanding of the problem space overall, as well as a<br>
better plan going forward than we had a few weeks ago.<br>
<span class=""><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>