Open Stack

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

>
>
> 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.
>
>
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-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/20160330/e7899170/attachment.html>