[openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?
armamig at gmail.com
Tue Mar 29 21:44:47 UTC 2016
On 29 March 2016 at 08:08, Matt Riedemann <mriedem at linux.vnet.ibm.com>
> Nova has had some long-standing bugs that Sahid is trying to fix here .
> 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 . 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 .
> 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.
>  https://review.openstack.org/#/c/284095/
>  https://review.openstack.org/#/c/173204/
> Matt Riedemann
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev