On Wed, Mar 30, 2016, at 03:54 PM, Matt Riedemann wrote: > > > On 3/30/2016 2:42 PM, Andrew Laski wrote: > > > > > > 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) - > > Selfishly I'd like Laski to be as focused on cells v2 as possible, but > he does have a spec up related to this.
At the midcycle I agreed to look into the oslo.policy work involved with this because I have some experience there. I wasn't planning to be much involved beyond that, and Claudiu has a spec up for the API side of it. But in my mind there's a chain backwards from capabilities API to discoverable policy and I want to move the oslo.policy work ahead quickly if I can to unblock that. > > >> 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. > > Agree to keep the priority list as small as possible, because this is > just a part of our overall backlog of priorities. > > >> > >> * Lower Priority Background Work * > >> > >> - POC of Gabbi for additional API validation > > I'm assuming cdent would be driving this, and he's also working on the > resource providers stuff for the scheduler, but might be a decent side > project for him to stay sane. > > >> - Microversion Testing in Tempest (underway) > > How much coverage do we have today? This could be like novaclient where > people just start hacking on adding tests for each microversion > (assuming gmann would be working on this). > > >> - 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. > > +1 > > > > > > >> - 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. > > +1 > > >> > >> * Things we need to decide this cycle * > >> > >> - When are we deleting the legacy v2 code base in tree? > > Do you have some high-level milestone thoughts here? I thought there was > talk about not even thinking about this until Barcelona? > > >> > >> * 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. > > Agree with Laski here. > > > > > > >> > >> 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. > > Thanks for writing this up. I'm trying to get all of the nova subteam > meetings on my calendar, but this one is hard for me to to make on time > given daycare duties each morning. > > >> > >> -Sean > >> > >> -- > >> Sean Dague > >> http://dague.net > >> > >> __________________________________________________________________________ > >> 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 > >> Email had 1 attachment: > >> + signature.asc > >> 1k (application/pgp-signature) > > > > __________________________________________________________________________ > > 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
