Bug 1445766 - Horizon is not reachable when Horizon service is running on a standalone role
Summary: Horizon is not reachable when Horizon service is running on a standalone role
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 11.0 (Ocata)
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: z5
: 11.0 (Ocata)
Assignee: Radomir Dopieralski
QA Contact: Udi Kalifon
URL:
Whiteboard:
Depends On:
Blocks: 1537168 1542203
TreeView+ depends on / blocked
 
Reported: 2017-04-26 13:08 UTC by Marius Cornea
Modified: 2022-07-09 09:59 UTC (History)
15 users (show)

Fixed In Version: openstack-tripleo-heat-templates-6.2.7-3.el7ost
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
: 1537168 1542203 (view as bug list)
Environment:
Last Closed: 2018-05-18 17:02:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 540982 0 None MERGED Open ports 443 and 80 on haproxy's firewall when horizon is standalone 2020-04-08 05:56:51 UTC
Red Hat Issue Tracker OSP-4630 0 None None None 2022-07-09 09:59:37 UTC
Red Hat Product Errata RHSA-2018:1627 0 None None None 2018-05-18 17:04:45 UTC

Description Marius Cornea 2017-04-26 13:08:21 UTC
Description of problem:
Horizon is not reachable when Horizon service is running on a standalone role. The firewall rules set on the nodes running HAProxy do not allow incoming tcp 80 or 443. Instead the rules allowing tcp 443 or 80 are set on the role running the Horizon service which requires only inbound connection to port tcp 80(coming from the HAProxy nodes).

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

How reproducible:
100%

Steps to Reproduce:
1. Deploy SSL enabled OSP11 with Horizon running on a custom role. Roles file:
http://paste.openstack.org/show/608060/
2. Try to reach Horizon:
[stack@undercloud-0 ~]$ curl https://10.0.0.101 -v
* About to connect() to 10.0.0.101 port 443 (#0)
*   Trying 10.0.0.101...

Actual results:
Timeout.

Expected results:
Horizon service is reachable.

Additional info:
Firewall rules on the controller node running HAProxy:
http://paste.openstack.org/show/608061/

Firewall rules on the horizon node:
http://paste.openstack.org/show/608057/

Comment 1 Radomir Dopieralski 2017-04-26 15:04:03 UTC
A short explanation of what I know so far:

In this particular configuration, you are not accessing horizon directly, but instead through a loadbalancer on the controller node. That loadbalancer is configured to proxy the traffic to the correct node, however, the ports on which
it does that are not open in its firewall configuration.

This is not a problem specific to Horizon, as that works fine on its own node. It just can't be accessed, because this one piece of configuration is missing. Of course this should be handled automatically by tripleo.

So this is something missing somewhere in our heat templates, that should tell puppet to open the ports when it configures haproxy to forward for Horizon.

The fix will most likely be in tripleo-heat-templates.

Comment 2 Alex Schultz 2017-04-26 15:45:51 UTC
I'm looking into this but I don't think this ever worked (even in 10) as the firewall rules would not end up on the right host if horizon is not collocated with haproxy.  Currently when splitting out horizon needs to be colocated with haproxy or an external load balancer needs to be used for it to work.

What's happening is that today the 80/443 firewall rule comes from the horizon service in THT. When it is not on the same node as haproxy, the 80/443 rule is only applied to the horizon node and haproxy is not configured to allow 80/443 connections.

Comment 4 Jason E. Rist 2017-04-26 16:46:41 UTC
Possible fix

https://review.openstack.org/#/c/460175

Comment 6 Lon Hohberger 2017-10-10 18:09:07 UTC
According to our records, this should be resolved by openstack-tripleo-heat-templates-6.2.0-3.el7ost.  This build is available now.

Comment 11 Emilien Macchi 2018-02-05 19:49:17 UTC
The bug wasn't backported to Ocata upstream and downstream.

Comment 25 errata-xmlrpc 2018-05-18 17:02:55 UTC
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:1627


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