Open Stack

On 3/29/2016 4:44 PM, Armando M. wrote:
>
>
> On 29 March 2016 at 08:08, Matt Riedemann <mriedem at linux.vnet.ibm.com
> <mailto: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://OpenStack-dev-request@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-request at 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.

-- 

Thanks,

Matt Riedemann