<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 29 March 2016 at 08: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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nova has had some long-standing bugs that Sahid is trying to fix here [1].<br>
<br>
You can create a network in neutron with port_security_enabled=False. However, the bug is that since Nova adds the 'default' security group to the request (if none are specified) when allocating networks, neutron raises an error when you try to create a port on that network with a 'default' security group.<br>
<br>
Sahid's patch simply checks if the network that we're going to use has port_security_enabled and if it does not, no security groups are applied when creating the port (regardless of what's requested for security groups, which in nova is always at least 'default').<br>
<br>
There has been a similar attempt at fixing this [2]. That change simply only added the 'default' security group when allocating networks with nova-network. It omitted the default security group if using neutron since:<br>
<br>
a) If the network does not have port security enabled, we'll blow up trying to add a port on it with the default security group.<br>
<br>
b) If the network does have port security enabled, neutron will automatically apply a 'default' security group to the port, nova doesn't need to specify one.<br>
<br>
The problem both Feodor's and Sahid's patches ran into was that the nova REST API adds a 'default' security group to the server create response when using neutron if specific security groups weren't on the server create request [3].<br>
<br>
This is clearly wrong in the case of network.port_security_enabled=False. When listing security groups for an instance, they are correctly not listed, but the server create response is still wrong.<br>
<br>
So the question is, how to resolve this?  A few options come to mind:<br>
<br>
a) Don't return any security groups in the server create response when using neutron as the backend. Given by this point we've cast off to the compute which actually does the work of network allocation, we can't call back into the network API to see what security groups are being used. Since we can't be sure, don't provide what could be false info.<br>
<br>
b) Add a new method to the network API which takes the requested networks from the server create request and returns a best guess if security groups are going to be applied or not. In the case of network.port_security_enabled=False, we know a security group won't be applied so the method returns False. If there is port_security_enabled, we return whatever security group was requested (or 'default'). If there are multiple networks on the request, we return the security groups that will be applied to any networks that have port security enabled.<br>
<br>
Option (b) is obviously more intensive and requires hitting the neutron API from nova API before we respond, which we'd like to avoid if possible. I'm also not sure what it means for the auto-allocated-topology (get-me-a-network) case. With a standard devstack setup, a network created via the auto-allocated-topology API has port_security_enabled=True, but I also have the 'Port Security' extension enabled and the default public external network has port_security_enabled=True. What if either of those are False (or the port security extension is disabled)? Does the auto-allocated network inherit port_security_enabled=False? We could duplicate that logic in Nova, but it's more proxy work that we would like to avoid.<br></blockquote><div><br></div><div>Port security on the external network has no role in this because this is not the network you'd be creating ports on. Even if it had port-security=False, an auto-allocated network will still be created with port security enabled (i.e. =True).</div><div><br></div><div>A user can obviously change that later on.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] <a href="https://review.openstack.org/#/c/284095/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/284095/</a><br>
[2] <a href="https://review.openstack.org/#/c/173204/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/173204/</a><br>
[3] <a href="https://github.com/openstack/nova/blob/f8a01ccdffc13403df77148867ef3821100b5edb/nova/api/openstack/compute/security_groups.py#L472-L475" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/f8a01ccdffc13403df77148867ef3821100b5edb/nova/api/openstack/compute/security_groups.py#L472-L475</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>