On 12 February 2016 at 09:15, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote:
> Forgive me for thinking out loud, but I'm trying to sort out how nova > would use a microversion in the nova API for the get-me-a-network feature > recently added to neutron [1] and planned to be leveraged in nova (there > isn't a spec yet for nova, I'm trying to sort this out for a draft). > > Originally I was thinking that a network is required for nova boot, so > we'd simply check for a microversion and allow not specifying a network, > easy peasy. > > Turns out you can boot an instance in nova (with neutron as the network > backend) without a network. All you get is a measly debug log message in > the compute logs [2]. That's kind of useless though and seems silly. > Incidentally, I was checking this out with Horizon, and the dashboard instance boot workflow doesn't let you proceed without specifying a network (irrespective of the network backend). So if the user has no networks, he/she is stuck and has to flip to the CLI. <sarcasm>Nice, uh</sarcasm>? > > I haven't tested this out yet to confirm, but I suspect that if you create > a nova instance w/o a network, you can latter try to attach a network using > the os-attach-interfaces API as long as you either provide a network ID > *or* there is a public shared network or the tenant has a network at that > point (nova looks those up if a specific network ID isn't provided). > Just to make sure we're on the same page: if you're referring to 'public shared network' as the devstack's provisioned network called 'public', that's technically not shared and it represent your floating IP pool. A user can explicitly boot VM's on it, but that's not to be confused with a 'shared' provider network. That said, I tried the workflow of booting a vm without networks and trying to attach an interface without specifying anything and I got a 500 [1]. Error aside, I think it's it would be erroneous to expect the attach command to accept no networks (and still pick one), when the boot command doesn't. [1] http://paste.openstack.org/show/486856/ > The high-level plan for get-me-a-network in nova was simply going to be if > the user tries to boot an instance and doesn't provide a network, and there > isn't a tenant network or public shared network to default to, then nova would call neutron's new auto-allocated-topology > API to get a network. This, however, is a behavior change. > I assume that for you 'public shared network' it's not the public network as available in DevStack because, because I don't believe that user can boot VM's on that network automatically. > So I guess the question now is how do we handle that behavior change in > the nova API? > > We could add an auto-create-net boolean to the boot server request which > would only be available in a microversion, then we could check that boolean > in the compute API when we're doing network validation. > > Today if you don't specify a network and don't have a network available, > then the validation in the API is basically just quota checking that you > can get at least one port in your tenant [3]. With a flag on a > microversion, we could also validate some other things about auto-creating > a network (if we know that's going to be the case once we hit the compute). > > Anyway, this is mostly me getting thoughts out of my head before the > weekend so I don't forget it and am looking for other ideas here or things > I might be missing. > John and I just finished talking about this a bit more and I think the the thought process led us to this conclusion: >From Horizon, we could provide a 'get-me-a-network' button on the Networks wizard for the boot workflow. If the user doesn't see any Networks available he/she can hit the button, see the network being pre-populated and choose to proceed, instead of going back to the Network panel and do the entire workflow. As for Nova, we could introduce a new micro-version that changes the behavior of nova boot without networks. In this case, if the tenant has access to no networks, one will be created for him/her and the VM will boot off of it. On the other end, if the user does want a VM without nics, he/she should be explicit about this and specify 'no-nic' boolean, e.g. nova boot <instance-name> --flavor <flavor-id> --image <image-id> --no-nics John and I think this would be preferable because the output of the command becomes more predictable: the user doesn't end up having VM's connected to NICs accidentally if some net-create sneaks underneath. Anyhow, food for thought. Thanks for starting this thread. Cheers, Armando > [1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network > [2] > https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595 > [3] > https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107 > > -- > > Thanks, > > Matt Riedemann > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev