Open Stack

There is a long contentious dev thread going on here [1] about how Nova 
should handle the Neutron auto-allocate-topology API (referred to as the 
'get-me-a-network' effort).

The point is to reduce the complexity for users to simply boot an 
instance and be able to ssh into it without having to first setup 
networks/subnets/routers in neutron and then specify a nic when booting 
the instance. If the planets are aligned, and no nic is provided (or 
available to the project), then nova would call the new neutron API to 
auto-allocate the network and use that to create a port to associate 
with the instance.

There is existing behavior in Nova where you can boot an instance and 
get no networking with neutron as the backend. You can later add 
networking by attaching an interface. The nova dev team has no idea how 
common this use case is though.

There will be a microversion to the nova API with the get-me-a-network 
support. The debate is what the default behavior should be when using 
that microversion. The options are basically:

1. If no nic is provided at boot and none are available, don't provide a 
network (existing behavior). If the user wants a network auto-allocated, 
they specify something like: --nic=auto

In this case the user has to opt into auto-allocating the network.

2. If no nic is provided at boot and none are available, nova will 
attempt to auto-allocate the network from neutron. If the user 
specifically doesn't want networking on instance create (for whatever 
reason), they have to opt into that behavior with something like: --nic=none

This is closer in behavior to how booting an instance works with 
nova-network, but it is a change in the default behavior for the neutron 
case, and that is a cause for concern for any users that have written 
tools to expect that default behavior.

3. If no nic is provided at boot and none are available, fail the 
request and force the request to be explicit, i.e. provide a specific 
nic, or auto, or none. This is a fail-fast scenario to force users to 
really state what they want.

--

As with any microversion change, we hope that users are reading the docs 
and aware of the changes in each microversion, but we can't guarantee 
that, so changing default behavior (case 2) requires discussion and 
input, especially from outside the dev team.

If you or your users have any input on this, please respond in this 
thread of the one in the -dev list.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086437.html

-- 

Thanks,

Matt Riedemann