[Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?
mordred at inaugust.com
Fri Feb 19 20:21:33 UTC 2016
On 02/19/2016 11:07 AM, Matt Riedemann wrote:
> There is a long contentious dev thread going on here  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:
> 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.
More information about the OpenStack-operators