Utility container cannot reach repo in play: name: Get list of repo packages

Bug #1800655 reported by Watteel
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openstack-ansible
Confirmed
Medium
Unassigned

Bug Description

in a openstack-ansible AIO install with release 18.0.0

followed manual:
https://docs.openstack.org/openstack-ansible/latest/user/aio/quickstart.html

all steps run successfull till step

openstack-ansible setup-infrastructure.yml

TASK [Get list of repo packages] ******************************************************************************************************************************************************************************
fatal: [aio1_utility_container-603e401d]: FAILED! => {"changed": false, "content": "", "msg": "Status code was -1 and not [200]: Request failed: <urlopen error [Errno 113] No route to host>", "redirected": false, "status": -1, "url": "http://172.29.236.100:8181/os-releases/18.0.0/centos-7.5-x86_64/requirements_absolute_requirements.txt"}

from the OA host i can reach the repo via the haproxy hosted ip
from the repo container i can reach the webservice running on the local ip
host can ping utility and repo container
both containers can ping the host and eachother

repo container can not reach the repo service via the haproxy
nmap of the service shows filtered in the container

Revision history for this message
Watteel (piwi3910) wrote :

running haproxy in debug doesn't see the utility containers traffic reach the haproxy

doing a tcpdump br-mgmt when going to the haproxy ip 172.29.236.100
however doing a ping, does show the traffic in tcpdump.

I'm lost here, the http traffic just seems to vanish when leaving the container

Revision history for this message
Watteel (piwi3910) wrote :

when running tcpdump on the container itself

i see this:

listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
17:44:02.472316 IP aio1-utility-container-603e401d.openstack.local.54720 > aio1.openstack.local.intermapper: Flags [S], seq 1614563767, win 29200, options [mss 1460,sackOK,TS val 20158751 ecr 0,nop,wscale 7], length 0
17:44:02.472445 IP aio1.openstack.local > aio1-utility-container-603e401d.openstack.local: ICMP host aio1.openstack.local unreachable - admin prohibited, length 68
17:44:03.474227 IP aio1-utility-container-603e401d.openstack.local.54720 > aio1.openstack.local.intermapper: Flags [S], seq 1614563767, win 29200, options [mss 1460,sackOK,TS val 20159754 ecr 0,nop,wscale 7], length 0
17:44:03.474335 IP aio1.openstack.local > aio1-utility-container-603e401d.openstack.local: ICMP host aio1.openstack.local unreachable - admin prohibited, length 68
17:44:07.480281 ARP, Request who-has aio1.openstack.local tell aio1-utility-container-603e401d.openstack.local, length 28
17:44:07.480301 ARP, Request who-has aio1-utility-container-603e401d.openstack.local tell aio1.openstack.local, length 28
17:44:07.480350 ARP, Reply aio1-utility-container-603e401d.openstack.local is-at 00:16:3e:1a:5f:db (oui Unknown), length 28
17:44:07.480342 ARP, Reply aio1.openstack.local is-at c6:1f:3a:d2:c0:37 (oui Unknown), length 28

Revision history for this message
Watteel (piwi3910) wrote :

flushing the iptables -F on the aio host fixes the problem.
so ansible is pushing some firewall rules in iptables that block the utility container for reaching the haproxy on the aio host

Revision history for this message
Mohammed Naser (mnaser) wrote :

We actually don't install any firewall rules so it seems like these have been put in place by another utility.

Changed in openstack-ansible:
status: New → Invalid
Revision history for this message
Mohammed Naser (mnaser) wrote :

We need to actually make sure that we document that firewalld should not be installed (or if it is, we need to make sure you have relaxed rules)

Changed in openstack-ansible:
status: Invalid → Confirmed
importance: Undecided → Medium
assignee: nobody → Mohammed Naser (mnaser)
assignee: Mohammed Naser (mnaser) → nobody
tags: added: low-hanging-fruit
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.