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
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
