On 29 March 2016 at 18:55, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote:
> > > On 3/29/2016 4:44 PM, Armando M. wrote: > >> >> >> On 29 March 2016 at 08:08, Matt Riedemann <mrie...@linux.vnet.ibm.com >> <mailto: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://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 >> >> > Yup, HenryG walked me through the cases on IRC today. > > 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. > > 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. > > 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? > > -- > > 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
