Open Stack

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy







On 2/19/16, 10:07 AM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com> 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.
>
>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

This is my preferred choice - keep the functionality exactly the same as the way it is today.  Users (if this is available) can opt-in.  Not 100% familiar with micro-version - but is it possible to opt-out of this micro-version all together, but have other, later, micro-versions?


>
>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.


I don't like this but I think other people might.  Really I would like to see a config option detailing how the cloud admin wants to handle this 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.

I don't like this option at all.  You are chaning what people must provide on the bootline and this as far as I can tell is a breaking change. 

>
>--
>
>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 at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators