On 3/31/2016 8:42 AM, Sahid Orentino Ferdjaoui wrote:
On Wed, Mar 30, 2016 at 09:46:45PM -0500, Matt Riedemann wrote:
On 3/30/2016 5:55 PM, Armando M. wrote:
On 29 March 2016 at 18:55, Matt Riedemann <mrie...@linux.vnet.ibm.com
<mailto: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>
<mailto: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://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://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://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
Today the network_api.validate_networks method called from the compute API
will check to see if the requested network exists (if one is requested), so
we could check the port_security_enabled value on that network then. If no
network is requested, we see if one is available to the project. If not, we
don't allocate networks on the initial server create. But if that's the
case, we'd just not return security groups I think since we don't know.
In the case of get-me-a-network with the auto-allocated-topology, we could
determine if security groups will be used by checking if the port-security
extension is enabled.
I'm not entirely sure how we'd get this information back from
network_api->compute_api->REST API though. We could set something in the
database for the instance and check that in the REST API, but that seems
hacky.
I think we do not have a real good solution to fix that case instead
of make the process "allocate networks for instance" synchrones so we
can retrieve network_info at this stage without to make the process to
heavy.
I'd suggest to just remove that field when port security extension is
enable and no security groups has been passed to the request.
s.
--
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
OK, so here is what we're going to do.
1. Add a release note to Sahid's change
https://review.openstack.org/#/c/284095/ saying that you can now boot
servers into networks that don't have port security enabled. However,
the server create response will still say that at least the default
security group is applied, which would be wrong in this case. We should
be able to backport this fix to stable branches.
2. We'll write up a spec to change the API response for server-create to
return a link for getting security groups rather than the list of
security groups we think are going to be applied (which might not be in
the case of neutron). Something like:
http://localhost:8774/v2.1/${project_id}/servers/{uuid}/os-security-groups
This is similar to how the server resource has links for the flavor it
was created with.
That will go in a microversion (which we can't backport since it's an
API change).
--
This is a bit of an odd case, but it's a trade-off to get the fix in
since not being able to boot an instance into a network that doesn't
have port security enabled is going to trump the UX in the server-create
response. Also, listing the security groups after the server is created
gives the correct results, so it's not like we're regressing that
functionality.
--
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
