Red Hat Bugzilla – Bug 1308562
Ceph monitor doesn't use the correct address for binding in IPv6 deployment
Last modified: 2016-04-07 17:28:27 EDT
Description of problem:
IPv6 deployment with 1 ctrl, 3 ceph nodes times out.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Deploy IPv6 environment with 1 x ctrl, 1 x compute, 3 ceph nodes
Deployment gets stuck because the client is trying to reach the ceph mon on the local address while the ceph mon binds on the storage vip address.
it looks like ceph-mon does not find the initial members list and binds on a local ip address from the public network instead of what is configured as mon_host in ceph.conf ... could need a require in the .pp forcing ::mon to be executed only after the config is dumped, investigating.
the problem is that ceph-mon won't find itself in the list of hosts given by 'mon host' and it will bind on the first local ip on the public network instead of what we pass in 'mon host'
this will be found in the ceph-mon logs
0 ceph version 0.94.1 (e4bfad3a3c51054df7e537a724c8d0bf9be972ff), process ceph-mon, pid 6053
0 mon.overcloud-controller-0 does not exist in monmap, will attempt to join an existing cluster
0 using public_addr [fd00:fd00:fd00:3000::10]:0/0 -> [fd00:fd00:fd00:3000::10]:6789/0
while 'mon_host' in ceph.conf had:
mon_host = [fd00:fd00:fd00:3000::14]
this could be a clone of https://bugzilla.redhat.com/show_bug.cgi?id=1301701
we might be able to override the standard binding mechanism using 'public addr' but this requires a change in puppet-ceph ; working on it
Not a blocker for 7.3. Moving to 8GA.
Merged upstream, built.
Verified by automation
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.