___________________________________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy
On 2/19/16, 10:07 AM, "Matt Riedemann" <mrie...@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@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
