<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 12 February 2016 at 09:15, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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).<br>
<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div>Incidentally, I was checking this out with Horizon, and the dashboard instance boot workflow doesn't let you proceed without specifying a network (irrespective of the network backend). So if the user has no networks, he/she is stuck and has to flip to the CLI. <sarcasm>Nice, uh</sarcasm>?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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).<br></blockquote><div><br></div><div>Just to make sure we're on the same page: if you're referring to 'public shared network' as the devstack's provisioned network called 'public', that's technically not shared and it represent your floating IP pool. A user can explicitly boot VM's on it, but that's not to be confused with a 'shared' provider network.</div><div><br></div><div>That said, I tried the workflow of booting a vm without networks and trying to attach an interface without specifying anything and I got a 500 [1]. Error aside, I think it's it would be erroneous to expect the attach command to accept no networks (and still pick one), when the boot command doesn't.</div><div> <br></div><div>[1] <a href="http://paste.openstack.org/show/486856/" target="_blank">http://paste.openstack.org/show/486856/</a><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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 </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">to default to, then nova would call neutron's new auto-allocated-topology API to get a network. This, however, is a behavior change.<br></blockquote><div><br></div><div>I assume that for you 'public shared network' it's not the public network as available in DevStack because, because I don't believe that user can boot VM's on that network automatically.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
So I guess the question now is how do we handle that behavior change in the nova API?<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br></blockquote><div><br></div><div>John and I just finished talking about this a bit more and I think the the thought process led us to this conclusion:</div><div><br></div><div>From Horizon, we could provide a 'get-me-a-network' button on the Networks wizard for the boot workflow. If the user doesn't see any Networks available he/she can hit the button, see the network being pre-populated and choose to proceed, instead of going back to the Network panel and do the entire workflow.</div><div><br></div><div>As for Nova, we could introduce a new micro-version that changes the behavior of nova boot without networks. In this case, if the tenant has access to no networks, one will be created for him/her and the VM will boot off of it.</div><div><br></div><div>On the other end, if the user does want a VM without nics, he/she should be explicit about this and specify 'no-nic' boolean, e.g.</div><div><br></div><div>  nova boot <instance-name> --flavor <flavor-id> --image <image-id> --no-nics </div><div><br></div><div>John and I think this would be preferable because the output of the command becomes more predictable: the user doesn't end up having VM's connected to NICs accidentally if some net-create sneaks underneath.</div><div><br></div><div>Anyhow, food for thought.</div><div><br></div><div>Thanks for starting this thread.</div><div><br></div><div>Cheers,</div><div>Armando</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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] <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] <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><span><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<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>
</font></span></blockquote></div><br></div></div>