Bug 1455503
| Summary: | external ip not correctly set for apache on 1+1 plus isolated ctlplane + external | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Eduard Barrera <ebarrera> |
| Component: | openstack-tripleo-heat-templates | Assignee: | Emilien Macchi <emacchi> |
| Status: | CLOSED NOTABUG | QA Contact: | Gurenko Alex <agurenko> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 10.0 (Newton) | CC: | aschultz, bfournie, mburns, pablo.iranzo, rhel-osp-director-maint, rob.w.crowe |
| Target Milestone: | --- | Keywords: | ZStream |
| Target Release: | 10.0 (Newton) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-03-27 17:18:06 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: | |||
I see a similar behavior. My external network is 9.0.0.0/16 and ports.conf is missing a "Listen 9.x.x.x:80" statement.
ServiceNetMap:
HorizonNetwork: external
stack@dir-01:/etc/httpd/conf$ cat ports.conf
# ************************************
# Listen & NameVirtualHost resources in module puppetlabs-apache
# Managed by Puppet
# ************************************
Listen 192.0.2.1:3000
Listen 192.0.2.1:35357
Listen 192.0.2.1:5000
Listen 192.0.2.1:8042
Listen 192.0.2.1:8774
Listen 192.0.2.1:8777
Listen 80
Actually I think my scenario is alittle different. The HAproxy rules are fine and list the external 9.x.x.x ip address its just httpd ports.conf that doesnt. So to the original bug, I don't think it's a valid configuration because Horizon does not proxy requests to the other endpoints so all services need to be on the same network as horizon for it to function correctly. Posting comments from Dan Sneddon when this issue was brought up on rhos-tech http://post-office.corp.redhat.com/archives/rhos-tech/2017-June/msg00253.html I think the issue is that you shouldn't be trying to put Horizon on the External network directly. Usually Horizon listens on the Internal API network, but HAProxy is configured to have a listener on the External network (which redirects to the Internal API network under normal circumstances). There are legacy reasons for this approach. Try using "ctlplane" for the Horizon network, and I think that might work better for you. Depending on which version you are using, it may not be possible to configure Horizon on the External network without also exposing the public APIs on the External network. Horizon runs largely inside the client browser, and makes direct API calls to the public APIs. I believe the newer versions perform SSL tunneling to prevent having to expose the APIs, but I'm not actually certain if that's been implemented. You should also check the final configuration to make sure that there aren't additional unwanted services listening on the External network due to the HAProxy config. Closing this based on Dan's comments. |
Description of problem: # This is a 1 + 1 example deployment, on top of infrared with 2 isolated networks, the idea is to have all the services on the provisioning network and making Horizon available to the external, we don't want anything else on the external network. #Issue ###this template results in all services listening on the provisioning network as expected but apache is not listening on the external. The 10-horizon-vhosts contains the external IP address on the virtualhost but there is no Listen directive on that IP. Then if I want to access horizon from the internal is not possible thus horizon virthost expect the external IP external: 10.0.0.0/24 brctlplane: 192.168.24.0/24 The haproxy rule is weird, it is binding on a ctrlplane IP and forwarding the requiest to the external network, but there is nothing listening there listen horizon bind 192.168.24.9:80 transparent mode http cookie SERVERID insert indirect nocache option forwardfor server overcloud-controller-0.external.localdomain 10.0.0.36:80 check cookie overcloud-controller-0 fall 5 inter 2000 rise 2 # ip a show br-ex 6: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN qlen 1000 link/ether 9a:5e:d5:a0:6e:4c brd ff:ff:ff:ff:ff:ff inet 10.0.0.36/24 brd 10.0.0.255 scope global br-ex valid_lft forever preferred_lft forever inet6 fe80::985e:d5ff:fea0:6e4c/64 scope link valid_lft forever preferred_lft forever # netstat -ntpl | grep ":80 " tcp 0 0 192.168.24.9:80 0.0.0.0:* LISTEN 108005/haproxy tcp 0 0 192.168.24.15:80 0.0.0.0:* LISTEN 77679/httpd #if I add a VIP, then all the services are exposed to the external network resource_registry: # This should point to the controller and compute yaml files we created before, # It tell to Director how we want the networking for the nodes OS::TripleO::Compute::Net::SoftwareConfig: ../custom/compute.yaml OS::TripleO::Controller::Net::SoftwareConfig: ../custom/controller.yaml # Port assignments for the controller role OS::TripleO::Controller::Ports::ExternalPort: ../network/ports/external.yaml OS::TripleO::Controller::Ports::InternalApiPort: ../network/ports/noop.yaml OS::TripleO::Controller::Ports::StoragePort: ../network/ports/noop.yaml OS::TripleO::Controller::Ports::StorageMgmtPort: ../network/ports/noop.yaml OS::TripleO::Controller::Ports::TenantPort: ../network/ports/noop.yaml OS::TripleO::Controller::Ports::ManagementPort: ../network/ports/noop.yaml # Port assignments for the compute role OS::TripleO::Compute::Ports::ExternalPort: ../network/ports/external.yaml OS::TripleO::Compute::Ports::InternalApiPort: ../network/ports/noop.yaml OS::TripleO::Compute::Ports::StoragePort: ../network/ports/noop.yaml OS::TripleO::Compute::Ports::StorageMgmtPort: ../network/ports/noop.yaml OS::TripleO::Compute::Ports::TenantPort: ../network/ports/noop.yaml OS::TripleO::Compute::Ports::ManagementPort: ../network/ports/noop.yaml OS::TripleO::Network::External: ../network/external.yaml parameter_defaults: ControlPlaneSubnetCidr: '24' ControlPlaneDefaultRoute: 192.168.24.1 EC2MetadataIp: 192.168.24.1 ExternalNetCidr: 10.0.0.0/24 ExternalAllocationPools: [{'start': '10.0.0.30', 'end': '10.0.0.60'}] ExternalInterfaceDefaultRoute: 10.0.0.1 DnsServers: ["8.8.8.8","8.8.4.4"] NeutronExternalNetworkBridge: "''" NeutronTunnelTypes: 'vxlan' ServiceNetMap: NeutronTenantNetwork: ctlplane CeilometerApiNetwork: ctlplane AodhApiNetwork: ctlplane GnocchiApiNetwork: ctlplane MongoDbNetwork: ctlplane CinderApiNetwork: ctlplane CinderIscsiNetwork: ctlplane GlanceApiNetwork: ctlplane GlanceRegistryNetwork: ctlplane KeystoneAdminApiNetwork: ctlplane KeystonePublicApiNetwork: ctlplane NeutronApiNetwork: ctlplane HeatApiNetwork: ctlplane NovaApiNetwork: ctlplane NovaMetadataNetwork: ctlplane NovaVncProxyNetwork: ctlplane SwiftMgmtNetwork: ctlplane SwiftProxyNetwork: ctlplane SaharaApiNetwork: ctlplane HorizonNetwork: external MemcachedNetwork: ctlplane RabbitMqNetwork: ctlplane RedisNetwork: ctlplane MysqlNetwork: ctlplane CephClusterNetwork: ctlplane CephPublicNetwork: ctlplane ControllerHostnameResolveNetwork: ctlplane ComputeHostnameResolveNetwork: ctlplane BlockStorageHostnameResolveNetwork: ctlplane ObjectStorageHostnameResolveNetwork: ctlplane CephStorageHostnameResolveNetwork: ctlplane Version-Release number of selected component (if applicable): 10 How reproducible: always Steps to Reproduce: 1. deploy the previous template 2. 3. Actual results: horizon not availabe from the external network Expected results: horizon available from the external network Additional info: