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

Sean Dague sean at dague.net
Thu Mar 31 11:20:39 UTC 2016


On 03/30/2016 05:27 PM, Andrew Laski wrote:
> 
> 
> 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.

Ok, so I think the summary of this is we should forget about a #3
priority item, and figure out how to move discoverable policy forward in
a real way this cycle, as that unblocks discoverable capabilities, which
unblocks virt features that are likely to not be widely deployed.

We should definitely carve some time at summit for that one.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list