Open Stack

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