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