Open Stack

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