On 29 March 2016 at 08:08, Matt Riedemann <mrie...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
