<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-03-31 5:36 GMT+08:00 Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span>:<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=""><div class="h5"><br>
<br>
On 3/30/2016 2:26 PM, Sean Dague 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">
During the Nova API meeting we had some conversations about priorities,<br>
but this feels like the thing where a mailing list conversation is more<br>
inclusive to get agreement on things. I think we need to remain focused<br>
on what API related work will have the highest impact on our users.<br>
(some brain storming was here -<br>
<a href="https://etherpad.openstack.org/p/newton-nova-api-ideas" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/newton-nova-api-ideas</a>). Here is a<br>
completely straw man proposal on priorities for the Newton cycle.<br>
<br>
* Top Priority Items *<br>
<br>
1. API Reference docs in RST which include microversions (drivers: me,<br>
auggy, annegentle) -<br>
<a href="https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst</a><br>
2. Discoverable Policy (drivers: laski, claudio) -<br>
<a href="https://review.openstack.org/#/c/289405/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/289405/</a><br>
3. ?? (TBD)<br>
<br>
I think realistically 3 priority items is about what we can sustain, and<br>
I'd like to keep it there. Item #3 has a couple of options.<br>
<br>
* Lower Priority Background Work *<br>
<br>
- POC of Gabbi for additional API validation<br>
- Microversion Testing in Tempest (underway)<br>
- Some of the API WG recommendations<br>
<br>
* Things we shouldn't do this cycle *<br>
<br>
- Tasks API - not because it's not a good idea, but because I think<br>
until we get ~ 3 core team members agreed that it's their number #1 item<br>
for the cycle, it's just not going to get enough energy to go somewhere<br>
useful. There are some other things on deck that we just need to clear<br>
first.<br>
- API wg changes for error codes - we should fix that eventually, but<br>
that should come as a single microversion to minimize churn. That's<br>
coordination we don't really have the bandwidth for this cycle.<br>
<br>
* Things we need to decide this cycle *<br>
<br>
- When are we deleting the legacy v2 code base in tree?<br>
</blockquote>
<br></div></div>
As discussed in IRC today, first steps (I think) are removing the deprecated 'osapi_v21.enabled' option in newton so v2.1 can't be disabled.<br>
<br>
And we need to think about logging a warning if you're using v2.0.<br>
<br>
That sets a timetable for removal of v2.0 in the O release at the earliest.<br></blockquote><div><br></div><div>If the target is O release, should we update v2.0 as 'DEPRECATED' in the version API, then we have a release to deprecated it</div><div><br></div><div>Currently it is still 'SUPPORTED' <a href="https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L11">https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L11</a></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>
We also talked about fixing bugs in v2.0 today and I plan on putting up a patch to the nova devref policy section about bug fixes for v2.0. Basically latent bugs won't be fixed unless they are blocking some other effort (NovaObjectDictCompat removal comes to mind) or fixes a security issue. And we shouldn't introduce new 500 errors in the v2.0 API.<br>
<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><div class="h5">
<br>
* Final priority item *<br>
<br>
For the #3 priority item one of the things that came up today was the<br>
structured errors spec by the API working group. That would be really<br>
nice... but in some ways really does need the entire new API reference<br>
docs in place. And maybe is better in O.<br>
<br>
One other issue that we've been blocking on for a while has been<br>
Capabilities discovery. Some API proposed adds like live resize have<br>
been conceptually blocked behind this one. Once upon a time there was a<br>
theory that JSON Home was a thing, and would slice our bread and julien<br>
our fries, and solve all this. But it's a big thing to get right, and<br>
JSON Home has an unclear future. And, we could server our users pretty<br>
well with a much simpler take on capabilities. For instance<br>
<br>
GET /servers/{id}/capabilities<br>
<br>
{<br>
"capabilities" : {<br>
"resize": True,<br>
"live-resize": True,<br>
"live-migrate": False<br>
...<br>
}<br>
}<br>
<br>
Effectively an actions map for servers. Lots of details would have to be<br>
sorted out on this one, clearly needs a spec, however I think that this<br>
would help unstick some other things people would like in Nova, without<br>
making our interop story terrible. This would need a driver for this effort.<br>
<br>
Every thing here is up for discussion. This is a summary of some of what<br>
was in the meeting, plus some of my own thoughts. Please chime in on any<br>
of this. It would be good to be of general agreement pre summit, so we<br>
could focus conversation there more on the hows for getting things done.<br>
<br>
-Sean<br>
<br>
<br>
<br></div></div><span class="">
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</span></blockquote><div class=""><div class="h5">
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>