In
0ceb5c0f3694725c7043ea99b077816da2ca44a7 I screwed up the version that
CRUSH_TUANBLES5 (chooseleaf_stable) was added: it comes from
043a7378ec4e828f2568ea3906d9076848161ccd, v10.0.3, which leads up to
jewel.
This, in turn, means that when jewel tunables are set we do not actually
encode the jewel tunables. At least, luminous doesn't; jewel uses a
different code path to decode how to encode the OSDMap.
This, in turn, leads to crc errors:
- luminous mons running
- require_osd_release is jewel
- jewel tunables are set. mon in-memory crushmap gets chooseleaf_stable=1
- osds are luminous, but don't see the new field in the crushmap
- upgrade finishes, and require_osd_Release becomes luminous
- the full osdmap encodes the chooseleaf_stable field, finally, and it
is 1
- the osds try to encode the same thing, but their crushmap has 0.
-> crc mismatch
This is a regression from
0ceb5c0f3694725c7043ea99b077816da2ca44a7,
backported to luminous in
686b054f48c50859bd5e8bad93007bf9d7d7899c in
12.2.6.
Fixes: 686b054f48c50859bd5e8bad93007bf9d7d7899c
Fixes: http://tracker.ceph.com/issues/25057
Signed-off-by: Sage Weil <sage@redhat.com>
}
if (require_osd_release < CEPH_RELEASE_KRAKEN) {
f &= ~(CEPH_FEATURE_SERVER_KRAKEN |
- CEPH_FEATURE_MSG_ADDR2 |
- CEPH_FEATURE_CRUSH_TUNABLES5);
+ CEPH_FEATURE_MSG_ADDR2);
}
if (require_osd_release < CEPH_RELEASE_JEWEL) {
f &= ~(CEPH_FEATURE_SERVER_JEWEL |
- CEPH_FEATURE_NEW_OSDOP_ENCODING);
+ CEPH_FEATURE_NEW_OSDOP_ENCODING |
+ CEPH_FEATURE_CRUSH_TUNABLES5);
}
return f;
}