On Fri, Feb 12, 2016, at 01:45 PM, John Garbutt wrote: > On 12 February 2016 at 18:17, Andrew Laski <and...@lascii.com> wrote: > > > > > > On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann 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. > >> > >> 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). > >> > >> 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. > >> > >> 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. > >> > > > > I think a flag like this is the right approach. If it's currently valid > > to boot an instance without a network than there needs to be something > > to distinguish a request that wants a network created vs. a request that > > doesn't want a network. > > > > This is still hugely useful if all that's required from a user is to > > indicate that they would like a network, they still don't need to > > understand/provide details of the network. > > I was thinking a sort of opposite. Would this work? > > We add a new micro-version that does this: > * nothing specified: do the best we can to get a port created > (get-me-a-network, etc,), or fail if not possible > * --no-nics option (or similar) that says "please don't give me any nics" > > This means folks that don't want a network, reliably have a way to do > that. For everyone else, we do the same thing when using either > neutron or nova-network VLAN manager.
I think this pushes our microversions meaning a bit further than intended. I don't think the API should flip behaviors simply based on a microversion. What about requiring nic information with the microversion? Make users indicate explicitly if they want a network or not and avoid changing a default behavior. > > Thanks, > johnthetubaguy > > PS > I think we should focus on the horizon experience, CLI experience, and > API experience separately, for a moment, to make sure each of those > cases actually works out OK. > > >> 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. > >> > >> [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 > > __________________________________________________________________________ > 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
