Bug 1291210
Summary: | backport to kilo: nova should not add default security group to quantum unless api-request had it | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Eduard Barrera <ebarrera> | ||||
Component: | openstack-nova | Assignee: | Sahid Ferdjaoui <sferdjao> | ||||
Status: | CLOSED ERRATA | QA Contact: | Prasanth Anbalagan <panbalag> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.0 (Kilo) | CC: | berrange, bschmaus, dasmith, dcadzow, dmaley, ebarrera, eglynn, jschluet, kchamart, kimi.zhang, majopela, sbauza, scorcora, sferdjao, sgordon, skinjo, srevivo, tbowling, vromanso | ||||
Target Milestone: | async | Keywords: | FeatureBackport, ZStream | ||||
Target Release: | 7.0 (Kilo) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | openstack-nova-2015.1.3-14.el7ost | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1331418 (view as bug list) | Environment: | |||||
Last Closed: | 2016-06-01 12:25:58 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1331418, 1331420 | ||||||
Attachments: |
|
Description
Eduard Barrera
2015-12-14 10:08:39 UTC
To get a DHCP server to work from an instance, the thing they were trying to do was right: neutron net-create test-port-security-disable -- --port_security_enabled=False Once you disable port security, you can serve DHCP from an instance, and instances can get any IP they want (because their source IP ins not going to be filtered by neutron)... But as eduard pointed out at point 4. [root@overcloud-compute-0 ~]# grep 92e83f34-c17d-4b37-815c-e93bd67c6eee /var/log/nova/nova-compute.log | grep " Security" 2015-12-06 20:08:37.852 17015 TRACE nova.compute.manager [instance: 92e83f34-c17d-4b37-815c-e93bd67c6eee] SecurityGroupCannotBeApplied: Network requires port_security_enabled and subnet associated in order to apply security groups. Nova should not try to apply or verify anything related to security groups when network has port security disabled. Could we see the neutron/server.log to verify neutron server is not complaining under the hood for some reason? Unfortunately Nova badly handle this port-security-enabled=False's option since Nova always set at least default security group. I'm currently working to provide a patch which should to makes Nova handle this option in a better way. Currently as a workaround you can continue to create network without to set port-security-enabled=False then use some commands from Neutron to update the port allocated to the instance. # neutron net-create net1 # neutron subnet-create net1 172.28.0.0/24 # nova boot --flavor m1.small --image cirros.qcow2 --nic net-id=<id-net1> i1 # neutron port-update <port-i1-id> --no-security-groups --port-security-enabled=False With <id-net1> Uniq ID of network created and <port-i1-id> Uniq id of port allocated to network <id-net1> for instance "i1". Please let me know any feedback. Thanks, s. Sahid, Thank you for the test build! Can you verify if they need to update to all of those packages built? Or only update the openstack-nova-compute and python-nova packages? Also, as I'm catching up on understanding the history, I have the following questions: 1. Is this behavior we're experiencing indeed caused by the fix on bz1167496? 2. Is this disabling port-security a recommended practice or use case? Are there any security ramifications we should relay to the customer or potential issues with future updates? Created attachment 1144583 [details]
server.log TRACES
The fix as now been approved. I don't think we can consider that sure the fact it will be backported in upstream-stable so we should to clone this bug for RHOS8 and RHOS9. In that time i'm working on providing hotfix soon. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1198 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |