New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jewel: osd: condition OSDMap encoding on features #12167
Conversation
Align this with decode. Signed-off-by: Sage Weil <sage@redhat.com> (cherry picked from commit 01d9e8a)
If the target features are missing the new OSDOp encoding, the first feature we added post-hammer, encode like hammer. Signed-off-by: Sage Weil <sage@redhat.com> (cherry picked from commit 2f8cfb6)
make check will fail on flake8: this is expected and harmless (environmental) |
@@ -3269,7 +3269,7 @@ bool OSDMonitor::preprocess_command(MonOpRequestRef op) | |||
rdata.append(osdmap_bl); | |||
ss << "got osdmap epoch " << p->get_epoch(); | |||
} else if (prefix == "osd getcrushmap") { | |||
p->crush->encode(rdata); | |||
p->crush->encode(rdata, CEPH_FEATURES_SUPPORTED_DEFAULT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not quorum features here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
they're going back to the cli caller; doesn't matter i guess
@@ -97,7 +97,7 @@ void OSDMonitor::_get_pending_crush(CrushWrapper& newcrush) | |||
if (pending_inc.crush.length()) | |||
bl = pending_inc.crush; | |||
else | |||
osdmap.crush->encode(bl); | |||
osdmap.crush->encode(bl, CEPH_FEATURES_SUPPORTED_DEFAULT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It turns out the features for the pending OSDMap::Incremental don't matter. The canonical mon map and the osdmap full map both encode from OSDMap.. they don't use the encoded crush in the incremental.
@@ -5569,7 +5569,7 @@ bool OSDMonitor::prepare_command_impl(MonOpRequestRef op, | |||
} | |||
|
|||
pending_inc.crush.clear(); | |||
newcrush.encode(pending_inc.crush); | |||
newcrush.encode(pending_inc.crush, CEPH_FEATURES_SUPPORTED_DEFAULT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not quorum features here, looks like you're updating the pending_inc, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meh.. okay, i'll make these consistent
::encode(*o->crush, oc); | ||
::encode(*n->crush, nc); | ||
::encode(*o->crush, oc, CEPH_FEATURES_SUPPORTED_DEFAULT); | ||
::encode(*n->crush, nc, CEPH_FEATURES_SUPPORTED_DEFAULT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this work if DEFAULT != the features actually used to encode the map?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah; all we're doing in an operator== on teh map itself; encoding is just our lame way to implementing that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, we're encoding both rather than comparing to an existing encoded buffer. Ok
I withdraw my questions, makes sense. |
a4bb664
to
aaf4a7f
Compare
Updated OSDMonitor.cc to be more consistent. |
jenkins test this please (ceph-disk test timedout https://jenkins.ceph.com/job/ceph-pull-requests/14870/console verifying this is real) |
A reminder to update the commit message at "crush/CrushWrapper: encode with features" and " crush/CrushWrapper: drop unused 'lean' encode() argument" to explain how the conflicts were resolved. |
jenkins test this please (unittest_pglog) |
make check passes at https://jenkins.ceph.com/job/ceph-pull-requests/14905/ with one expected failure (flake8) |
this is incomplete; still seeing an encoding disparity i need to track down |
I take it back--I think the last issue is fixed, this should be ready. Also merge this with ceph-qa-suite: ceph/ceph-qa-suite#1285 |
http://pulpito.ceph.com/sage-2016-11-28_16:58:23-upgrade:hammer-x-jewel---basic-smithi/ calling this a pass wrt to the osdmap encoding changes.. 👍 on merging this! |
@liewegas do you want this in for 10.2.4 |
No callers, no users. Signed-off-by: Sage Weil <sage@redhat.com> (cherry picked from commit 638a38b) Conflicts: src/crush/CrushWrapper.h [trivial conflict due to removal of write_file and read_file]
No behavior change yet; just fixing callers. Signed-off-by: Sage Weil <sage@redhat.com> (cherry picked from commit b7c9e05) [Updated write_file to use all feaetures] [Updated OSDMonitor.cc to use mon->quorum_features instead of the mon->get_quorum_con_featuers() helper] [trivial conflict from removed write_file and read_file] Conflicts: src/crush/CrushWrapper.h src/mgr/PyModules.cc src/mon/OSDMonitor.cc src/tools/ceph_monstore_tool.cc
This avoids throwing hammer OSDMap encodings off. Signed-off-by: Sage Weil <sage@redhat.com> (cherry picked from commit 9e5ff86)
aaf4a7f
to
4d6f848
Compare
updated commit messages about (trivial) conflicts |
yes please
|
test this please |
test this please (jenkins hasty expiration of logs) |
@liewegas @dachary this has passed the rados run (with exception of valgrind issue) and details captured here http://tracker.ceph.com/issues/17487#note-37, Do you think it is ready to be merged into jewel yet? |
the make check failure is only about flake8 and is expected (https://jenkins.ceph.com/job/ceph-pull-requests/15330/) |
http://tracker.ceph.com/issues/18015