<div dir="ltr">Perhaps another option for '--nic'? nova boot --nic auto-allocate</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 12, 2016 at 10:17 AM, Andrew Laski <span dir="ltr"><<a href="mailto:andrew@lascii.com" target="_blank">andrew@lascii.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:<br>
> Forgive me for thinking out loud, but I'm trying to sort out how nova<br>
> would use a microversion in the nova API for the get-me-a-network<br>
> feature recently added to neutron [1] and planned to be leveraged in<br>
> nova (there isn't a spec yet for nova, I'm trying to sort this out for a<br>
> draft).<br>
><br>
> Originally I was thinking that a network is required for nova boot, so<br>
> we'd simply check for a microversion and allow not specifying a network,<br>
> easy peasy.<br>
><br>
> Turns out you can boot an instance in nova (with neutron as the network<br>
> backend) without a network. All you get is a measly debug log message in<br>
> the compute logs [2]. That's kind of useless though and seems silly.<br>
><br>
> I haven't tested this out yet to confirm, but I suspect that if you<br>
> create a nova instance w/o a network, you can latter try to attach a<br>
> network using the os-attach-interfaces API as long as you either provide<br>
> a network ID *or* there is a public shared network or the tenant has a<br>
> network at that point (nova looks those up if a specific network ID<br>
> isn't provided).<br>
><br>
> The high-level plan for get-me-a-network in nova was simply going to be<br>
> if the user tries to boot an instance and doesn't provide a network, and<br>
> there isn't a tenant network or public shared network to default to,<br>
> then nova would call neutron's new auto-allocated-topology API to get a<br>
> network. This, however, is a behavior change.<br>
><br>
> So I guess the question now is how do we handle that behavior change in<br>
> the nova API?<br>
><br>
> We could add an auto-create-net boolean to the boot server request which<br>
> would only be available in a microversion, then we could check that<br>
> boolean in the compute API when we're doing network validation.<br>
><br>
<br>
</div></div>I think a flag like this is the right approach. If it's currently valid<br>
to boot an instance without a network than there needs to be something<br>
to distinguish a request that wants a network created vs. a request that<br>
doesn't want a network.<br>
<br>
This is still hugely useful if all that's required from a user is to<br>
indicate that they would like a network, they still don't need to<br>
understand/provide details of the network.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> Today if you don't specify a network and don't have a network available,<br>
> then the validation in the API is basically just quota checking that you<br>
> can get at least one port in your tenant [3]. With a flag on a<br>
> microversion, we could also validate some other things about<br>
> auto-creating a network (if we know that's going to be the case once we<br>
> hit the compute).<br>
><br>
> Anyway, this is mostly me getting thoughts out of my head before the<br>
> weekend so I don't forget it and am looking for other ideas here or<br>
> things I might be missing.<br>
><br>
> [1] <a href="https://blueprints.launchpad.net/neutron/+spec/get-me-a-network" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/neutron/+spec/get-me-a-network</a><br>
> [2]<br>
> <a href="https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595</a><br>
> [3]<br>
> <a href="https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107</a><br>
><br>
> --<br>
><br>
> Thanks,<br>
><br>
> Matt Riedemann<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>