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