Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1393487 - Manila port is not open in firewall when deploying the Manila API service on a different role than controller
Manila port is not open in firewall when deploying the Manila API service on ...
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates (Show other bugs)
10.0 (Newton)
Unspecified Unspecified
unspecified Severity urgent
: rc
: 10.0 (Newton)
Assigned To: Tom Barron
Dustin Schoenbrun
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-11-09 11:28 EST by Marius Cornea
Modified: 2016-12-14 11:31 EST (History)
9 users (show)

See Also:
Fixed In Version: openstack-tripleo-heat-templates-5.0.0-1.7.el7ost
Doc Type: Bug Fix
Doc Text:
OpenStack Platform director did not update firewall when deploying OpenStack File Share API (manila-api). If you moved the manila-api service off controllers to its own role, the default firewall rules blocked the endpoints. This fix updates the manila-api firewall rules in the overcloud Heat template collection. You can now reach the endpoints even when manila-api is on a role separate from the controller nodes.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-14 11:31:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1640568 None None None 2016-11-09 14:23 EST
OpenStack gerrit 396183 None None None 2016-11-10 08:11 EST
Red Hat Product Errata RHEA-2016:2948 normal SHIPPED_LIVE Red Hat OpenStack Platform 10 enhancement update 2016-12-14 14:55:27 EST

  None (edit)
Description Marius Cornea 2016-11-09 11:28:23 EST
Description of problem:
Manila port is not open in firewall when deploying the service on a different role than controller:

Deploy command and environment files:
http://paste.openstack.org/show/588586/

Version-Release number of selected component (if applicable):
openstack-tripleo-heat-templates-5.0.0-1.4.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Deploy overcloud with Manila on a different role than controller
2. Check iptables rules on role running Manila API

Actual results:
iptables -nL | grep 8786
There is no accept rule so access to Manila API from haproxy is blocked.

Expected results:
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 8786 /* 100 manila_haproxy */ state NEW

Additional info:
Workaround:
iptables -I INPUT -p tcp -m multiport --dports 8786 -m comment --comment "100 manila_haproxy" -m state --state NEW -j ACCEPT
Comment 3 Dustin Schoenbrun 2016-11-23 16:08:18 EST
I tested this against the 2016-11-19.4 puddle and was able to modify the /usr/share/openstack-tripleo-heat-templates/roles_data.yaml file to move the Manila API service from the default location of the controller nodes to the compute nodes and then deploy my overcloud as such. At the end of the deployment I was able to call the Manila API successfully, verify that the correct iptables rules were set on the compute node, and that the service was started successfully on the compute node.
Comment 5 errata-xmlrpc 2016-12-14 11:31:17 EST
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://rhn.redhat.com/errata/RHEA-2016-2948.html

Note You need to log in before you can comment on or make changes to this bug.