Open Stack

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.

>
>
>>>> 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-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)
>>> __________________________________________________________________________
>>> 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
> __________________________________________________________________________
> 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