Open Stack

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