Open Stack

2016-03-31 5:36 GMT+08:00 Matt Riedemann <mriedem at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/0bcdeca3/attachment.html>