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. 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
