[openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?
john at johngarbutt.com
Fri Feb 12 18:45:11 UTC 2016
On 12 February 2016 at 18:17, Andrew Laski <andrew at 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  and planned to be leveraged in
>> nova (there isn't a spec yet for nova, I'm trying to sort this out for a
>> 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 . 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 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 . 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.
>>  https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
>> Matt Riedemann
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev