Rsyslogd stores all remote logs in '172.17.42.1' folder
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Fuel for OpenStack |
Fix Committed
|
High
|
Bogdan Dobrelya | ||
| 5.0.x |
Fix Committed
|
High
|
Bogdan Dobrelya | ||
Bug Description
api: '1.0'
astute_sha: 694b5a55695e01e
build_id: 2014-06-20_00-31-14
build_number: '262'
fuellib_sha: 25eb618a33a2ec8
fuelmain_sha: 4f547561532baf5
mirantis: 'yes'
nailgun_sha: 0c5e3b94fdd6bc9
ostf_sha: 2f30e5cab5bec1f
production: docker
release: '5.1'
Steps to reproduce:
1. Deploy master node, boot slaves
2. Go to 'Logs' tab and check logs from slave nodes
Expected:
- got the list of bootstrap logs and their content
Actual result:
- remote logs aren't available
Also, remote logs don't appear after successful cluster deployment. The reason of this issue is iptables rule added to the top of 'POSTROUTING' chain:
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 4 226 MASQUERADE all -- * * 10.108.180.0/24 0.0.0.0/0
It causes masquerading of all packets sent to rsyslog container, so it stores all logs to the /var/log/
| Artem Panchenko (apanchenko-8) wrote | #1 |
| Changed in fuel: | |
| status: | New → In Progress |
| assignee: | Fuel Library Team (fuel-library) → Bogdan Dobrelya (bogdando) |
| Bogdan Dobrelya (bogdando) wrote | #2 |
| Bogdan Dobrelya (bogdando) wrote | #3 |
| OpenStack Infra (hudson-openstack) wrote Fix proposed to fuel-library (master) | #4 |
| Dmitry Borodaenko (angdraug) wrote | #5 |
| OpenStack Infra (hudson-openstack) wrote Fix merged to fuel-library (master) | #6 |
| Changed in fuel: | |
| status: | In Progress → Fix Committed |
| OpenStack Infra (hudson-openstack) wrote Fix proposed to fuel-library (stable/5.0) | #7 |
| OpenStack Infra (hudson-openstack) wrote Fix merged to fuel-library (stable/5.0) | #8 |
The source of the issue is that the rule from ./deployment/
$rule = "-s $network -j MASQUERADE"
command => "iptables -t nat -I POSTROUTING 1 $rule; \
wants to be the very first while the Fuel master node is deploying. That rule is needed in order to provide the routing options for OSt nodes via the Fuel master node.
But for some cases (like this one in the ticket), the docker containers startup process could place its own "very first" rules ahead,
./deployment/
iptables -t nat -I POSTROUTING 1 -s "$NETWORK/$PREFIX" -p $proto -m $proto --dport $port -j ACCEPT
As a result we'd have result in the broken NAT chain then we've got an admin network masquerading rule have been placed before the docker rules.
The solution is to add an admin network masquerading rule with the -A option instead of -I 1. That would do the trick unless we have placed the blocking rules at the end of the NAT list. We don't use any for now, so it is OK to do so...