On 12 February 2016 at 11:08, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote:
> > > On 2/12/2016 12:44 PM, Armando M. wrote: > >> >> >> On 12 February 2016 at 09:15, Matt Riedemann <mrie...@linux.vnet.ibm.com >> <mailto: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. >> > > I was referring to this code: > > > https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L217-L223 > > Ok I am with you: the public in the comment is somewhat misleading because there's nothing 'public' about a shared network and as a matter of fact RBAC [1] allows for networks to be shared only to a subset of tenants. [1] https://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html > >> 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/ >> > > Cool, yeah, I was totally expecting an IndexError because of the code here: > > > https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L610 > > > >> >> 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. >> > > Yeah, I replied to John's post and I think we're all basically on the same > page, it's just a matter of implementation details, but we're in agreement > that by default (with the microversion), you're going to get a network > allocated if you don't bring one or have one available, unless you > explicitly opt out of that with some flag on the request. > I think we're understanding the problem space a bit more, for sure. Hopefully we have all the building blocks in place to execute on this. > > >> 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://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 >> >> > -- > > 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