On Mon, Feb 22, 2016 at 10:58 AM, Matt Riedemann <[email protected]> wrote: > > > On 2/20/2016 5:29 PM, Matt Riedemann wrote: >> >> >> >> On 2/19/2016 4:48 PM, Kris G. Lindgren wrote: >>> >>> >>> >>> ___________________________________________________________________ >>> Kris Lindgren >>> Senior Linux Systems Engineer >>> GoDaddy >>> >>> >>> >>> >>> >>> >>> >>> On 2/19/16, 10:07 AM, "Matt Riedemann" <[email protected]> >>> 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? >> >> >> Users/clients opt into a microversion by specifying a header with the >> version in the request. You can't skip microversions. If your client >> support 2.10 and then you wanted to support 2.18, for example, you have >> to also build in support for handling 2.11-2.17. >> >>> >>> >>>> >>>> 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. >> >> >> With the push for more consistent API behavior across public OpenStack >> clouds, making the API configurable with config options is not really a >> thing we want to do anymore since it's not discoverable. If cloud A >> doesn't support this but cloud B does, even though you've specified the >> same microversion for both, it's confusing and unreliable. Of course we >> already have some of this situation already since not all of the virt >> driver backends support 100% of the REST API, but I don't think we want >> to add to that if we can help it. > > > Thinking about this again today, nova is going to be checking that the > auto-allocate-topolocy extension is enabled in neutron. So if you just don't > enable that extension, you've effectively disabled the nic=auto option in > nova. Basically like a config option.
Only you kinda can't: https://github.com/openstack/neutron/blob/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0/neutron/plugins/common/constants.py#L41 get-me-a-network is enabled by default, so if you're running a recent enough Neutron you're just going to get that extension enabled. > > >> >>> >>>> >>>> 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. >> >> >> Yes it's a breaking change, but with a microversion you have to opt into >> it, so you have to be aware of it when you make the request. Just FYI. >> >>> >>>> >>>> -- >>>> >>>> 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 >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> > > -- > > Thanks, > > Matt Riedemann > > > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
