Bug 1590458
| Summary: | Backport support for specifying security group protocol numbers | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | David Hill <dhill> |
| Component: | openstack-neutron | Assignee: | Brian Haley <bhaley> |
| Status: | CLOSED ERRATA | QA Contact: | Roee Agiman <ragiman> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 12.0 (Pike) | CC: | afariasa, amuller, bhaley, chrisw, dcadzow, dhill, jamsmith, moddi, nyechiel, ragiman, slinaber, srevivo |
| Target Milestone: | z3 | Keywords: | FeatureBackport, Triaged, ZStream |
| Target Release: | 12.0 (Pike) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-neutron-11.0.4-1.el7ost | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-08-20 12:51:35 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: | |||
We also need this one in neutron:
commit 7ff492c5bb9ce9f24f12db40c8e3a33beb47f87b
Author: Brian Haley <bhaley>
Date: Thu Oct 12 15:25:26 2017 -0400
Support protocol numbers in security group API
Somewhere along the way we broke supporting numbers in
the security group API that were not in our known list
of protocols. In order to fix this properly we must
use the correct arguments when using iptables-save, as
it could use a name instead of a number, or vice-versa.
Determined the list of mappings by doing:
for num in {0..255}; do iptables -A INPUT -p $num; done
# iptables-save
Change-Id: I5895250b47ddf664d214cf085be693c3897e0c87
Closes-bug: #1716045
Closes-bug: #1716790
Hello, Customer from case https://gss--c.na7.visual.force.com/apex/Case_View?id=500A000000b7kNe&sfdc.override=1 reported that they are able to create the security group using --protocol 4 in their environment, they`re currently running OSP12 and bellow I posted his env installed pakages. I would like to know why it's working in his env, and not on the env I recently deployed with OSP12 using director? Customer had his environemnt upgraded to OSP12 from OSP11, where the security group are supposed to work. Customer Environemnt: on compute: rpm -qa | grep openstack openstack-neutron-11.0.2-1.el7ost.noarch python-openstackclient-lang-3.12.0-1.el7ost.noarch openstack-nova-compute-16.0.4-5.el7ost.noarch python-openstackclient-3.12.0-1.el7ost.noarch openstack-neutron-openvswitch-11.0.2-1.el7ost.noarch openstack-utils-2015.2-1.el7ost.noarch openstack-nova-common-16.0.4-5.el7ost.noarch python-openstacksdk-0.9.17-1.el7ost.noarch openstack-neutron-ml2-11.0.2-1.el7ost.noarch openstack-selinux-0.8.13-2.el7ost.noarch openstack-neutron-common-11.0.2-1.el7ost.noarch On controller: rpm -qa | grep openstack openstack-dashboard-12.0.2-1.el7ost.noarch openstack-cinder-11.1.0-1.el7ost.noarch openstack-neutron-common-11.0.2-1.el7ost.noarch openstack-nova-api-16.0.4-5.el7ost.noarch openstack-heat-engine-9.0.3-1.el7ost.noarch openstack-utils-2015.2-1.el7ost.noarch python-openstacksdk-0.9.17-1.el7ost.noarch openstack-nova-conductor-16.0.4-5.el7ost.noarch openstack-neutron-openvswitch-11.0.2-1.el7ost.noarch openstack-keystone-12.0.0-4.el7ost.noarch python-openstackclient-3.12.0-1.el7ost.noarch openstack-heat-common-9.0.3-1.el7ost.noarch openstack-nova-common-16.0.4-5.el7ost.noarch openstack-nova-scheduler-16.0.4-5.el7ost.noarch openstack-nova-novncproxy-16.0.4-5.el7ost.noarch openstack-neutron-ml2-11.0.2-1.el7ost.noarch openstack-heat-api-9.0.3-1.el7ost.noarch openstack-nova-console-16.0.4-5.el7ost.noarch openstack-heat-api-cfn-9.0.3-1.el7ost.noarch openstack-dashboard-theme-12.0.0-3.el7ost.noarch python-django-openstack-auth-3.5.0-3.el7ost.noarch openstack-neutron-lbaas-ui-3.0.1-3.el7ost.noarch openstack-neutron-lbaas-11.0.2-2.el7ost.noarch openstack-glance-15.0.0-4.el7ost.noarch python-openstackclient-lang-3.12.0-1.el7ost.noarch openstack-neutron-11.0.2-1.el7ost.noarch openstack-nova-placement-api-16.0.4-5.el7ost.noarch openstack-heat-api-cloudwatch-9.0.3-1.el7ost.noarch openstack-selinux-0.8.13-2.el7ost.noarch So we just pulled stable/pike downstream, so this fix should be in the latest candidate package, openstack-neutron-11.0.4-1.el7ost 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-2018:2514 |
Description of problem: Backport ipencap (ipip) support from queens to pike in neutron-lib commit f4c4b0f20a796caf2133f6029ca3455382cd50ad Author: German Eichberger <German.eichberger> Date: Tue Sep 12 15:18:46 2017 -0600 Adds IPinIP protocol Neutron doesn't support the IP-in-IP protocol by name in security group rules. With this change a user can now declare the IP-in-IP protocol by using the name 'ipip' Note: This doesn't fix an underlying problem with the Neutron protocol number validator, but serves as a work around for users wanting to use the IP-in-IP protocol. Partial-bug: #1716045 Change-Id: I18e5e42b687e12b64f5a9c523a912c8dd1afa9d2 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: