> On Feb 12, 2016, at 12:03 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com> > wrote: > > > > On 2/12/2016 12: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. >> >> 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 >> > > I think we're basically looking at the same use case. And as Kevin noted I > was thinking an option on the --nic part of the request, like auto-allocate.
I thought one of the original notions behind this was to make ‘nova boot’ as simple as in the nova-net case, which would imply not needing to use —nic at all. I personally like the idea of the flag being for the no network case. doug > > My thinking was with the microversion, that defaults to True and you have to > opt-in to the old behavior (specify auto-allocate=False) of nova being OK > with not providing any network for the instance. The flag that goes down > through the compute API and neutronv2 API code would default to False for > backward compat, we'd just default the option to True in the REST API if not > explicitly provided. > > -- > > 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
