<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 29 March 2016 at 18:55, 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"><span class=""><br>
<br>
On 3/29/2016 4:44 PM, Armando M. wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On 29 March 2016 at 08:08, Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>>> wrote:<br>
<br>
Nova has had some long-standing bugs that Sahid is trying to fix<br>
here [1].<br>
<br>
You can create a network in neutron with<br>
port_security_enabled=False. However, the bug is that since Nova<br>
adds the 'default' security group to the request (if none are<br>
specified) when allocating networks, neutron raises an error when<br>
you try to create a port on that network with a 'default' security<br>
group.<br>
<br>
Sahid's patch simply checks if the network that we're going to use<br>
has port_security_enabled and if it does not, no security groups are<br>
applied when creating the port (regardless of what's requested for<br>
security groups, which in nova is always at least 'default').<br>
<br>
There has been a similar attempt at fixing this [2]. That change<br>
simply only added the 'default' security group when allocating<br>
networks with nova-network. It omitted the default security group if<br>
using neutron since:<br>
<br>
a) If the network does not have port security enabled, we'll blow up<br>
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<br>
automatically apply a 'default' security group to the port, nova<br>
doesn't need to specify one.<br>
<br>
The problem both Feodor's and Sahid's patches ran into was that the<br>
nova REST API adds a 'default' security group to the server create<br>
response when using neutron if specific security groups weren't on<br>
the server create request [3].<br>
<br>
This is clearly wrong in the case of<br>
network.port_security_enabled=False. When listing security groups<br>
for an instance, they are correctly not listed, but the server<br>
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<br>
when using neutron as the backend. Given by this point we've cast<br>
off to the compute which actually does the work of network<br>
allocation, we can't call back into the network API to see what<br>
security groups are being used. Since we can't be sure, don't<br>
provide what could be false info.<br>
<br>
b) Add a new method to the network API which takes the requested<br>
networks from the server create request and returns a best guess if<br>
security groups are going to be applied or not. In the case of<br>
network.port_security_enabled=False, we know a security group won't<br>
be applied so the method returns False. If there is<br>
port_security_enabled, we return whatever security group was<br>
requested (or 'default'). If there are multiple networks on the<br>
request, we return the security groups that will be applied to any<br>
networks that have port security enabled.<br>
<br>
Option (b) is obviously more intensive and requires hitting the<br>
neutron API from nova API before we respond, which we'd like to<br>
avoid if possible. I'm also not sure what it means for the<br>
auto-allocated-topology (get-me-a-network) case. With a standard<br>
devstack setup, a network created via the auto-allocated-topology<br>
API has port_security_enabled=True, but I also have the 'Port<br>
Security' extension enabled and the default public external network<br>
has port_security_enabled=True. What if either of those are False<br>
(or the port security extension is disabled)? Does the<br>
auto-allocated network inherit port_security_enabled=False? We could<br>
duplicate that logic in Nova, but it's more proxy work that we would<br>
like to avoid.<br>
<br>
<br>
Port security on the external network has no role in this because this<br>
is not the network you'd be creating ports on. Even if it had<br>
port-security=False, an auto-allocated network will still be created<br>
with port security enabled (i.e. =True).<br>
<br>
A user can obviously change that later on.<br>
<br>
<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]<br>
<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><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></div></div>
<<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 class=""><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>
<br>
Yup, HenryG walked me through the cases on IRC today.<br>
<br>
The more I think about option (b) above, the less I like that idea given how much work goes into the allocate_for_instance code in nova where it's already building the list of possible networks that will be used for creating/updating ports, we'd essentially have to duplicate that logic in a separate method to get an idea of what security groups would be applied.<br>
<br>
I'd prefer to be lazy and go with option (a) and just say nova doesn't return security-groups in the REST API when creating a server and neutron is the network API. That would require a microversion probably, but it would still be easy to do. I'm not sure if that's the best user experience though.<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>At the very least nova-api checks that the network exists before proceeding; is it crazy or doable checking for the port security attribute on the network and set a sentinel value for security groups before moving on?</div><div><br></div><div> </div><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>
<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>