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