<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 8 November 2016 at 18:35, 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:1px solid rgb(204,204,204);padding-left:1ex">I've been looking at this nova bug:<br>
<br>
<a href="https://bugs.launchpad.net/nova/+bug/1637118" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nov<wbr>a/+bug/1637118</a><br>
<br>
And the neutronv2 API code in nova and need some help from the neutron team on how this should actually work.<br></blockquote><div><br></div><div>If I am not mistaken [1] is what we'd need on the nova side.</div><div><br></div><div>As for neutron, we implemented [2], which can be leveraged by [1] in order to implement the non-backward compatible behavior of lifting the constraint check should a port be required without an address.</div><div><br></div><div>Mind you, I said port intentionally, meaning that even with [1], bug 1637118 would still manifest itself (in other words, it would be the expected behavior). Booting off unaddressed VMs is an advanced use case and as such it requires to boot by specifying the port ID.</div><div><br></div><div>[1] <a href="https://blueprints.launchpad.net/neutron/+spec/vm-without-l3-address" target="_blank">https://blueprints.launchpad.<wbr>net/neutron/+spec/vm-without-<wbr>l3-address</a><br></div><div><div>[2] <a href="https://blueprints.launchpad.net/nova/+spec/vm-boot-with-unaddressed-port" target="_blank">https://blueprints.launchpad.<wbr>net/nova/+spec/vm-boot-with-<wbr>unaddressed-port</a> </div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The validation code that runs from nova-api when creating a server checks the requested/available networks to see if they have subnets and if not it's a failure. The original change that added that way back in icehouse was because you'd get a security group could not be applied failure when trying to create ports on a network with port security enabled but that didn't have subnets.<br>
<br>
Now the code in nova that creates the port, which happens in nova-compute, handles this - it only fails if the network doesn't have subnets if the network has port security enabled. If the network doesn't have port security enabled, we don't care about subnets before creating the port.<br>
<br>
However, that icehouse-era validation code that happens in the API side before casting to the compute is still there, and that's what the bug is saying is a problem.<br>
<br>
So that sounds like a legitimate issue, but I wanted to get confirmation from the neutron team first before moving forward with a fix.<span class="m_7402273431044203222gmail-HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></blockquote></div><br></div></div>