On our public cloud we do exactly as Robert describes - as part of our customer onboarding process, we automatically create a default network and router to our provider network, so that a tenant can just spin up a VM if they want to. Obviously the customer can then delete this if they wish, but it gets them started.
On 25 February 2016 at 00:19, Robert Starmer <rob...@kumul.us> wrote: > Most service environments I've worked with will deploy (often > automatically) a first tenant network and router, allowing for the simple > case of "deploy a vm, and it auto attaches to the only network" model. So > in effect, this is anticipated, if not expected, behavior. If on the other > hand, there is no network, does the auto-network process also create a > router, and associate that router with an "external" network with floating > address/etc.? If not, then isn't the --nic=auto case effectively > equivalent to the no network case anyway? there's still neutron work to be > done, and the VM will likely need to have a DHCP lease re-established if a > router is also attached so that the network has anything other than local > meaning. > > I.e., what was the original use case of this auto-created network (which > sounds like it's here to stay regardless). Does someone have a pointer to > the spec that defines the use case of this. > > But even so, I'd say I prefer model 2 over the others, but perhaps a > warning needs to be generated, especially if the network isn't router > connected automatically, otherwise, the end user is going to be confused as > to why internet connectivity isn't available ("I see a network attached, > but I can't get to the internet"). > > Just my $0.02 > Robert > > On Mon, Feb 22, 2016 at 1:18 PM, Assaf Muller <amul...@redhat.com> wrote: > >> On Mon, Feb 22, 2016 at 10:58 AM, Matt Riedemann >> <mrie...@linux.vnet.ibm.com> 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" <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? >> >> >> >> >> >> 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 >> >>>> OpenStack-operators@lists.openstack.org >> >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> >> >> >> > >> > -- >> > >> > 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 >> > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- DataCentred Limited registered in England and Wales no. 05611763
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators