Description of problem: When adding Octavia Version-Release number of selected component (if applicable): OSP 13 RC How reproducible: Deploy an overcloud without Octavia and then run an update deployment including the Octavia environment file in order to add Octavia. The firewall rules for the Octavia APIs will not be added to the controller nodes. Steps to Reproduce: 1.Deploy an OSP13 overcloud without Octavia enabled 2.Observe that no Octavia firewall rules are present 3.Re-run the overcloud deployment including the Octavia environment file 4.Observe that Octavia is deployed and running 5.Observe that the firewall rule for octavia-housekeeping is created, but not the rules for octavia-api 6.Tear down the overcloud and build it fresh with Octavia enabled 7.Observe that firewall rules are created normally for all Octavia services Actual results: Following the update deployment, firewall rules for octavia-housekeeping are created but not for octavia-api. Expected results: All firewall rules should be created on the update deployment as well as a fresh deployment. Additional info:
Andrew showed me his deployment. I confirmed the firewall rules were not created. I will have a look at this issue.
Hi Brent, Could this issue be related to bug 1451829? In new deployments, we know the rules for octavia-api exist (otherwise our testing would have failed). The issue Andrew is reporting about happens when you add Octavia to an already existing deployment. We need to document this for OSP13 GA as a known issue while suggesting the operating how to add the missing firewall rule(s) manually. For OSP13 z-stream we should solve it on TripleO. Can you please have a glimpse at this and tell which rule is missing here?
I'm in the process of setting up an environment to troubleshoot this issue. Brent and I will be pairing up.
Upstream patches linked in rhbz#1559105 should fix this issue too. I am at the moment testing them with manual cherry-picks on an OSP13 GA deployment.
I can confirm that patches [1] and [2] fixed this issue too. [root@controller-0 heat-admin]# iptables -n -L | grep octavia ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 9876 state NEW /* 100 octavia_haproxy ipv4 */ ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 13876 state NEW /* 100 octavia_haproxy_ssl ipv4 */ ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 5555 state NEW /* 200 octavia health manager interface ipv4 */ [root@controller-0 heat-admin]# ip6tables -n -L | grep octavia ACCEPT tcp ::/0 ::/0 multiport dports 9876 state NEW /* 100 octavia_haproxy ipv6 */ ACCEPT tcp ::/0 ::/0 multiport dports 13876 state NEW /* 100 octavia_haproxy_ssl ipv6 */ ACCEPT udp ::/0 ::/0 multiport dports 5555 state NEW /* 200 octavia health manager interface ipv6 */ (overcloud) [stack@undercloud-0 ~]$ openstack loadbalancer list -v START with options: [u'loadbalancer', u'list', u'-v'] command: loadbalancer list -> octaviaclient.osc.v2.load_balancer.ListLoadBalancer (auth=True) Using auth plugin: password END return value: 0 [1] https://review.openstack.org/574263 [2] https://review.openstack.org/574264
(In reply to Andrew Austin from comment #0) > Description of problem: > When adding Octavia > > Version-Release number of selected component (if applicable): > OSP 13 RC > > How reproducible: > Deploy an overcloud without Octavia and then run an update deployment > including the Octavia environment file in order to add Octavia. The firewall > rules for the Octavia APIs will not be added to the controller nodes. > > Steps to Reproduce: > 1.Deploy an OSP13 overcloud without Octavia enabled Done > 2.Observe that no Octavia firewall rules are present Not present Present > 3.Re-run the overcloud deployment including the Octavia environment file Here it fails ( Virt setup) is this a common way of updating the cloud ?
Alex, could you please provide more details of how are you trying to update and of the failure you're getting? You'd have saved us a round-trip. Enabling Octavia can be done by adding the THT environment file of Octavia to the 'openstack overcloud deploy' command, and re-run it. I did that on a virtual environment and it worked well.
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/RHSA-2018:2214