<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 12 February 2016 at 11:08, 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"><span><br>
<br>
On 2/12/2016 12:44 PM, Armando M. wrote:<br>
</span><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"><span>
<br>
<br>
On 12 February 2016 at 09:15, Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a><br></span><div><div>
<mailto:<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>>> wrote:<br>
<br>
Forgive me for thinking out loud, but I'm trying to sort out how<br>
nova would use a microversion in the nova API for the<br>
get-me-a-network feature recently added to neutron [1] and planned<br>
to be leveraged in nova (there isn't a spec yet for nova, I'm trying<br>
to sort this out for a draft).<br>
<br>
Originally I was thinking that a network is required for nova boot,<br>
so we'd simply check for a microversion and allow not specifying a<br>
network, easy peasy.<br>
<br>
Turns out you can boot an instance in nova (with neutron as the<br>
network backend) without a network. All you get is a measly debug<br>
log message in the compute logs [2]. That's kind of useless though<br>
and seems silly.<br>
<br>
<br>
Incidentally, I was checking this out with Horizon, and the dashboard<br>
instance boot workflow doesn't let you proceed without specifying a<br>
network (irrespective of the network backend). So if the user has no<br>
networks, he/she is stuck and has to flip to the CLI. <sarcasm>Nice,<br>
uh</sarcasm>?<br>
<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<br>
provide a network ID *or* there is a public shared network or the<br>
tenant has a network at that point (nova looks those up if a<br>
specific network ID isn't provided).<br>
<br>
<br>
Just to make sure we're on the same page: if you're referring to 'public<br>
shared network' as the devstack's provisioned network called 'public',<br>
that's technically not shared and it represent your floating IP pool. A<br>
user can explicitly boot VM's on it, but that's not to be confused with<br>
a 'shared' provider network.<br>
</div></div></blockquote>
<br>
I was referring to this code:<br>
<br>
<a href="https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L217-L223" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L217-L223</a><span><br>
<br></span></blockquote><div><br></div><div>Ok I am with you: the public in the comment is somewhat misleading because there's nothing 'public' about a shared network and as a matter of fact RBAC [1] allows for networks to be shared only to a subset of tenants.<br></div><div><br></div><div>[1] <a href="https://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html" target="_blank">https://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html</a></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"><span>
<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>
That said, I tried the workflow of booting a vm without networks and<br>
trying to attach an interface without specifying anything and I got a<br>
500 [1]. Error aside, I think it's it would be erroneous to expect the<br>
attach command to accept no networks (and still pick one), when the boot<br>
command doesn't.<br>
<br>
[1] <a href="http://paste.openstack.org/show/486856/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/486856/</a><br>
</blockquote>
<br></span>
Cool, yeah, I was totally expecting an IndexError because of the code here:<br>
<br>
<a href="https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L610" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L610</a><div><div><br>
<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">
<br>
<br>
The high-level plan for get-me-a-network in nova was simply going to<br>
be if the user tries to boot an instance and doesn't provide a<br>
network, and there isn't a tenant network or public shared network<br>
<br>
to default to, then nova would call neutron's new<br>
auto-allocated-topology API to get a network. This, however, is a<br>
behavior change.<br>
<br>
<br>
I assume that for you 'public shared network' it's not the public<br>
network as available in DevStack because, because I don't believe that<br>
user can boot VM's on that network automatically.<br>
<br>
<br>
So I guess the question now is how do we handle that behavior change<br>
in the nova API?<br>
<br>
We could add an auto-create-net boolean to the boot server request<br>
which would only be available in a microversion, then we could check<br>
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<br>
available, then the validation in the API is basically just quota<br>
checking that you can get at least one port in your tenant [3]. With<br>
a flag on a microversion, we could also validate some other things<br>
about auto-creating a network (if we know that's going to be the<br>
case once we 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>
<br>
John and I just finished talking about this a bit more and I think the<br>
the thought process led us to this conclusion:<br>
<br>
From Horizon, we could provide a 'get-me-a-network' button on the<br>
Networks wizard for the boot workflow. If the user doesn't see any<br>
Networks available he/she can hit the button, see the network being<br>
pre-populated and choose to proceed, instead of going back to the<br>
Network panel and do the entire workflow.<br>
<br>
As for Nova, we could introduce a new micro-version that changes the<br>
behavior of nova boot without networks. In this case, if the tenant has<br>
access to no networks, one will be created for him/her and the VM will<br>
boot off of it.<br>
<br>
On the other end, if the user does want a VM without nics, he/she should<br>
be explicit about this and specify 'no-nic' boolean, e.g.<br>
<br>
nova boot <instance-name> --flavor <flavor-id> --image <image-id><br>
--no-nics<br>
<br>
John and I think this would be preferable because the output of the<br>
command becomes more predictable: the user doesn't end up having VM's<br>
connected to NICs accidentally if some net-create sneaks underneath.<br>
</blockquote>
<br></div></div>
Yeah, I replied to John's post and I think we're all basically on the same page, it's just a matter of implementation details, but we're in agreement that by default (with the microversion), you're going to get a network allocated if you don't bring one or have one available, unless you explicitly opt out of that with some flag on the request.<br></blockquote><div><br></div><div>I think we're understanding the problem space a bit more, for sure. Hopefully we have all the building blocks in place to execute on this.</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>
<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"><span>
<br>
Anyhow, food for thought.<br>
<br>
Thanks for starting this thread.<br>
<br>
Cheers,<br>
Armando<br>
<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></span>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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><span><br>
<br>
<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>
<br>
</span></blockquote><div><div>
<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>
</div></div></blockquote></div><br></div></div>