On 2/14/16, 3:59 PM, "Ken'ichi Ohmichi" <ken1ohmi...@gmail.com> wrote:
>2016-02-12 11:19 GMT-08:00 Andrew Laski <and...@lascii.com>: >> 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. > >I agree with alaski's point here. >The default behavior changes can hurt API users easily even if bumping >a microversion because it is difficult to pay attentions for all >microversions' changes(we have already 22 microversions now) from >users' viewpoints. Were there any cross project discussions about this feature or are we discussing this after the fact? I do not think that we should be changing the default behavior. > >Thanks >Ken Ohmichi > >__________________________________________________________________________ >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