On Wednesday morning the Nova and Neutron teams got together for a
design summit session. The full etherpad is here [1].
We talked through three major items.
1. Neutron routed networks.
Carl Baldwin gave a quick recap that we're on track with the Nova spec
[2] and had pushed a new revision which addressed Dan Smith's latest
comments. The spec is highly dependent on Jay Pipes'
generic-resource-pools spec which needs to be rebated, and then
hopefully we can approve that this week and the routed networks one
shortly thereafter.
We spent some time with Dan Smith sketching out his idea for moving the
neutron network allocation code from the nova compute node to conductor.
This would help with a few things:
a) Doing the allocation earlier in the process so it's less expensive if
we fail on the compute and get into a retry loop.
b) It should clean up a bunch of the allocation code that's in the
network API today, so we can separate the allocation logic from the
check/update logic. This would mean that by the time we get to the
compute the ports are already allocated and we just have to check back
with Neutron that they are still correct and update their details. And
that would also mean by the time we get to the compute it looks the same
whether the user provided the port at boot time or Nova allocated it.
c) Nova can update it's allocation tables before scheduling to make a
more informed decision about where to place the instance based on what
Neutron has already told us is available.
John Garbutt is planning on working on doing this cleanup/refactor to
move parts of the network allocation code from the compute to conductor.
We'll most likely need a spec for this work.
2. Get Me a Network
We really just talked about two items here:
a) With the microversion, if the user requests 'auto' network allocation
and there are no available networks for the project and dry-run
validation for auto-allocated-topology fails on the Neutron side (the
default public network and subnet pool aren't setup), we'll fail the API
request with a 409. I had asked if we should fall back to the existing
behavior of just not allocating networking, but we decided that it will
be better to be explicit about a failure if you're requesting 'auto'. In
most cases projects already have a network available to them when their
cloud provider sets up their project, so they won't even get to the
auto-allocated network topology code being written for the spec. But if
not, it's a failure and not allocating networking is just...weird. Plus
you can opt into the 'none' behavior with the microversion if that's
what you really want.
b) There were some questions about making get-me-a-network more advanced
than the networking that is setup today (a tenant network behind a
router). The agreement was that get-me-a-network is for the case that
the user doesn't care, they just want networking for their instance in
Nova. Anything that's more advanced should be pre-allocated in Neutron
and the instance in Nova should be booted with the network/port that was
pre-allocated in Neutron. There might be future changes/customization to
the type of network created from the auto-allocated-topology API in
Neutron, but that should be dealt with only in Neutron and not a concern
of Nova.
3. Deprecating nova-network.
The rest of the session was spent discussing the (re)deprecation of
nova-network. Given the recent couple of user surveys, it's clear that
deployments have shifted to using Neutron.
We have some gaps in the Nova REST API but we can work each of those on
a case-by-case basis. For example, we won't implement the
os-virtual-interfaces API for Neutron. Today it returns a 400, that
could maybe use a more appropriate error code, but it won't be changed
to be a 200. And for the os-limits API which returns some compute and
network resource quota limits info, we can microversion it to simply not
return the network resources if you're using Neutron. Once we drop
nova-network we'll update the API again to not return those network
resources at all, you'll get them from Neutron (if you aren't already).
We also decided it's not worth deprecating nova-network in pieces since
it gets messy and something might force us to add feature parity if it's
not deprecated outright, like cells v2.
And we said it's not worth splitting it out into it's own repo since
that has cost of it's own to maintain. If people want to fork the repo
to keep using it, that's on them but it won't be supported by the Nova
team once it's removed.
So given the above, Sean proposed the deprecation patch [3] which by now
is already (eagerly) approved. Note that there isn't a timetable on the
actual removal, it could be as early as Ocata, but we need to address
the REST API gaps and virt driver CI testing that's using it today. So
we'll see where we're at during the midcycle and once we get to Ocata to
see if it's possible to remove it.
I have to say, given where we are now with the second attempt at
deprecating nova-network, it was much more obvious this time around.
This is a testament to the hard work that the Neutron team has been
doing for the last few releases to stabilize, test, document and
generally improve the project so that we are able to get here.
[1] https://etherpad.openstack.org/p/newton-nova-neutron
[2] https://review.openstack.org/#/c/263898/
[3] https://review.openstack.org/#/c/310539/
--
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
