osdc/Objecter: fix split vs reconnect race

If we are reconnecting to an OSD, we may not have a connection established
so this feature check is completely unreliable.  If there happens to be a
split, that could mean we don't resend an op that should have been resent.

Instead, we can infer the OSD has the new behavior if require_osd_release
is luminous or later.  If not, we can look at the per-osd features in the
OSDMap.

Fixes: http://tracker.ceph.com/issues/22544
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 917fdbe5422d099902aaa08b3406efc0247ef155)

diff --git a/src/osdc/Objecter.cc b/src/osdc/Objecter.cc
index c7851e91c8e53e01dca04c628955def4ee84d96e..ddcf7a4c1659344ada573ddbaf893d4cba71ee1f 100644 (file)
--- a/src/osdc/Objecter.cc
+++ b/src/osdc/Objecter.cc
@@ -2952,7 +2952,10 @@ int Objecter::_calc_target(op_target_t *t, Connection *con, bool any_change)
   if (legacy_change || unpaused || force_resend) {
     return RECALC_OP_TARGET_NEED_RESEND;
   }
-  if (split && con && con->has_features(CEPH_FEATUREMASK_RESEND_ON_SPLIT)) {
+  if (split &&
+      (osdmap->require_osd_release >= CEPH_RELEASE_LUMINOUS ||
+       HAVE_FEATURE(osdmap->get_xinfo(acting_primary).features,
+                   RESEND_ON_SPLIT))) {
     return RECALC_OP_TARGET_NEED_RESEND;
   }
   return RECALC_OP_TARGET_NO_ACTION;