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.
--
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
