Open Stack

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.