On 02/19/2016 11:07 AM, Matt Riedemann wrote:
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.
Fascinating. I have never wanted to do this. I cannot imagine wanting to
do this. I also have never heard anyone express a desire to do this.
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:
The command line tool always uses the latest microversion, right?
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.
This would not be horrible, but still requires a user to take an action
that they would not expect to need to do just to do the simple thing
(boot a vm) So it's my least favorite.
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.
This is my most favorite - because it accomplishes the simplest case
"boot me a vm without me requesting anything out of the ordinary about
it" in the simplest way "nova boot"
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.
I like this better than 1 but less than 2. The nice part is that the
error message can at least communicate to the user that they need to say
"--nic=$something" - which is at least active communication on our part.
But if there is no network available, then the _only_ valid choices are
none and auto, (specific nic wouldn't be a result here because in that
case the user currently gets the "I can't figure out which network to
use" errror - and again the "no" nic is a strange case that is the least
likely thing a user wants to do.
--
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.
That is totally fair and I think you're right about that. It is a change
- but in this particular case I think we can extrapolate pretty well
about what people do and how they use clouds.
Getting an IP address in an OpenStack Cloud is hard already - AND it's
very common for clouds to restrict API calls for port/fixed-ip
manipulation, so I doubt VERY seriously that anyone is deliberately
going through additional needless steps to get a working IP.
If you or your users have any input on this, please respond in this
thread of the one in the -dev list.
I earnestly suggest #2. I believe it is the behavior users are more
likely to expect than anything else.
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
