On Wed, Mar 30, 2016, at 04:47 PM, Adam Young wrote: > On 03/30/2016 04:16 PM, Andrew Laski wrote: > > > > 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. > > There is a CLI that does something like what you want already: > > https://review.openstack.org/#/c/170978/ > > You basically want a server based version of that that returns all the > "true" values.
Exactly. The shortcoming of the CLI is that not all policies are guaranteed to be defined in a policy.json file. It's entirely possible for there to be a policy check with no definition anywhere which will just fall back to a defined default rule. A big part of my policy proposal(https://review.openstack.org/#/c/290155/) is to require policies to be registered in code like configuration options are. This allows for an exhaustive check against all used policies. And will allow for policy file generation from services. > > > > > > >>>> 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 > > > __________________________________________________________________________ > 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
