[openstack-dev] [nova] API priorities in Newton

Andrew Laski andrew at lascii.com
Wed Mar 30 19:42:42 UTC 2016



On Wed, Mar 30, 2016, at 03: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.

Agreed. I would love to drive this forward but there are just too many
other areas to focus on right now.


> - 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?
> 
> * 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.

I think this ties directly into the discoverable policy item above. I
may be misunderstanding this proposal but I would expect that it has
some link with what a user is allowed to do. Without some improvements
to the policy handling within Nova this is not currently possible.


> 
> 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
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __________________________________________________________________________
> 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
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)



More information about the OpenStack-dev mailing list