Open Stack

On 29 March 2016 at 08:08, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

> Nova has had some long-standing bugs that Sahid is trying to fix here [1].
>
> 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.
>
> 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').
>
> 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:
>
> 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.
>
> 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.
>
> 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].
>
> 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.
>
> So the question is, how to resolve this?  A few options come to mind:
>
> 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.
>
> 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.
>
> 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.
>

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).

A user can obviously change that later on.


>
> [1] https://review.openstack.org/#/c/284095/
> [2] https://review.openstack.org/#/c/173204/
> [3]
> https://github.com/openstack/nova/blob/f8a01ccdffc13403df77148867ef3821100b5edb/nova/api/openstack/compute/security_groups.py#L472-L475
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160329/4af307b8/attachment.html>