Skip to content
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

Merged
5 commits merged into from Dec 5, 2016

Conversation

liewegas
Copy link
Member

@liewegas liewegas commented Nov 23, 2016

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)
@liewegas liewegas added this to the jewel milestone Nov 23, 2016
@liewegas liewegas added the core label Nov 23, 2016
@ghost ghost changed the title osd: condition OSDMap encoding on features (jewel) jewel: osd: condition OSDMap encoding on features (jewel) Nov 23, 2016
@ghost ghost self-assigned this Nov 23, 2016
@ghost ghost added the bug-fix label Nov 23, 2016
@ghost
Copy link

ghost commented Nov 23, 2016

make check will fail on flake8: this is expected and harmless (environmental)

@ghost ghost changed the title jewel: osd: condition OSDMap encoding on features (jewel) jewel: osd: condition OSDMap encoding on features Nov 23, 2016
@@ -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);
Copy link
Contributor

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?

Copy link
Member Author

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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or here?

Copy link
Member Author

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);
Copy link
Contributor

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?

Copy link
Member Author

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);
Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Contributor

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

@athanatos
Copy link
Contributor

I withdraw my questions, makes sense.

@liewegas
Copy link
Member Author

Updated OSDMonitor.cc to be more consistent.

@ghost
Copy link

ghost commented Nov 24, 2016

jenkins test this please (ceph-disk test timedout https://jenkins.ceph.com/job/ceph-pull-requests/14870/console verifying this is real)

@ghost
Copy link

ghost commented Nov 24, 2016

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.

@ghost
Copy link

ghost commented Nov 24, 2016

jenkins test this please (unittest_pglog)

@ghost
Copy link

ghost commented Nov 24, 2016

make check passes at https://jenkins.ceph.com/job/ceph-pull-requests/14905/ with one expected failure (flake8)

@liewegas liewegas changed the title jewel: osd: condition OSDMap encoding on features DNM: jewel: osd: condition OSDMap encoding on features Nov 26, 2016
@liewegas
Copy link
Member Author

this is incomplete; still seeing an encoding disparity i need to track down

@liewegas liewegas changed the title DNM: jewel: osd: condition OSDMap encoding on features jewel: osd: condition OSDMap encoding on features Nov 26, 2016
@liewegas
Copy link
Member Author

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

@liewegas
Copy link
Member Author

@liewegas
Copy link
Member Author

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!

@theanalyst
Copy link
Member

@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)
@liewegas
Copy link
Member Author

updated commit messages about (trivial) conflicts

@liewegas
Copy link
Member Author

liewegas commented Nov 28, 2016 via email

@theanalyst
Copy link
Member

test this please

@ghost
Copy link

ghost commented Dec 5, 2016

test this please (jenkins hasty expiration of logs)

@theanalyst
Copy link
Member

@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?

@ghost
Copy link

ghost commented Dec 5, 2016

the make check failure is only about flake8 and is expected (https://jenkins.ceph.com/job/ceph-pull-requests/15330/)

@ghost ghost merged commit a944491 into ceph:jewel Dec 5, 2016
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants