The teuthology test did not like the change to remove 'mon addr' from
ceph.conf. The standalone script is easier to test.
Note that it avoids mon names 'a', 'b', 'c' since the MonMap::build_initial
uses those.
Signed-off-by: Sage Weil <sage@redhat.com>
Do not try to bind to v2 addresses until all of the mons will know what
we are doing and will be able to advertise those addresses.
This avoids the possibility of corner cases where we bind to one thing
but advertise something different via the various cluster maps.
Signed-off-by: Sage Weil <sage@redhat.com>
This primarily kicks in if we connect to a mon's v1 address during the
initial probe and then discover that it has v2+v1. It's a catch-all,
though, so that we'll reconnect to the (er, a) mon in any case where we
see it's addresses change.
Signed-off-by: Sage Weil <sage@redhat.com>
The grace starts with the monmap creation stamp, and ceph.py does a lot
of work between creating that map and actually starting daemons (e.g.,
preparing all of the osd devices), leading to occasional MGR_DOWN errors.
Double the grace period.
Signed-off-by: Sage Weil <sage@redhat.com>
Teuthology no longer puts mon addr in ceph.conf, and instead sets the
mon_host option globally. That means a different path for
ceph-monstore-tool rebuild to regenerate the monmap, and the generated
map's names need to match teuthologies.
This change fixes the teuthology rebuild test because that tests's mon
names happen to also be 'a', 'b', 'c'. It's fragile, but it works.
Signed-off-by: Sage Weil <sage@redhat.com>
We may have learned our address from a v1 connection, so myaddrs() is
a v1 addr like [v1:1.2.3.4:123/4392]. When we connect to someone using
msgr2, we should advertise ourselves as a v2 address, or else we risk
confusing everyone because we are a "v1" endpoint using the v2 protocol.
Signed-off-by: Sage Weil <sage@redhat.com>
If we are (potentially) replacing a connection, assert that the protocol
version matches. If it doesn't, something very weird is going on!
Signed-off-by: Sage Weil <sage@redhat.com>
The --add option will only infer a bare IP to include a v2 addr if the
NAUTILUS feature is there, and that isn't normally present on a freshly
generate monmap. Add it if we are doing addrvecs!
Signed-off-by: Sage Weil <sage@redhat.com>
This field isn't populated for loopback connections because the msgr
doesn't have any insight into what global_id its user has.
Signed-off-by: Sage Weil <sage@redhat.com>
If we get a connection on a loopback from ourselves, get_source_addrs()
will have everything we bound to, but the mdsmap may only have the v1
address. Avoid the addrvec comparison by instead comparing the
ConnectionRefs.
NOTE: this implementation is a stopgap. We should really maintain a map
of ConnectionRefs for the current up set and compare the ConnectionRefs
directly instead of comparing addr(vecs).
Signed-off-by: Sage Weil <sage@redhat.com>
The features are now stored in the protocol implementation. When we replace
an existing connection, copy those features so that our connect_msg_reply
calculates the correct features for the session.
This fixes an issue where a 3-mon cluster, after upgrading the two followers
but not the leader, was unable to include the (luminous) leader in the
quorum because it was seeing missing features in the connect reply, because
the new mons were replacing an old instance of the connection and weren't
copying the features, and that old instance had connect_msg.features == 0.
Add some debug lines that helped (finally) identify the problem.
Signed-off-by: Sage Weil <sage@redhat.com>
Having these live in teuthology.git is silly, since they are only consumed
by the ceph task, and it is hard to revise the behavior.
Revise the behavior by adding mon_bind_* options.
Signed-off-by: Sage Weil <sage@redhat.com>
