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

mon: load stashed map before mkfs monmap #40660

Merged
merged 1 commit into from
May 13, 2021
Merged

Conversation

dvanders
Copy link
Contributor

@dvanders dvanders commented Apr 8, 2021

After mkfs the store may not yet contain monmap:last_committed but
might be respawning after setting mon_sync:temp_newer_monmap.
Load that stashed map before falling back to the mkfs:monmap.

Fixes: https://tracker.ceph.com/issues/50230
Signed-off-by: Dan van der Ster daniel.vanderster@cern.ch

After mkfs the store may not yet contain monmap:last_committed but
might be respawning after setting mon_sync:temp_newer_monmap.
Load that stashed map before falling back to the mkfs:monmap.

Fixes: https://tracker.ceph.com/issues/50230
Signed-off-by: Dan van der Ster <daniel.vanderster@cern.ch>
@github-actions github-actions bot added the core label Apr 8, 2021
@dvanders dvanders requested a review from liewegas April 8, 2021 10:16
@dvanders
Copy link
Contributor Author

dvanders commented Apr 8, 2021

I tested this change -- it solves our bootstrapping problem.

Copy link
Member

@neha-ojha neha-ojha left a comment

Choose a reason for hiding this comment

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

makes sense to me, @liewegas do you see any issues with this approach?

Copy link
Contributor

@tchaikov tchaikov left a comment

Choose a reason for hiding this comment

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

this change should work. but i think it might be better if we could make the "mon_sync:temp_newer_monmap" machinery more explicit. it was introduced back in https://tracker.ceph.com/issues/44076, and its purpose was to break the respawn loop of the monitor whose addresses changes in the latest map by overriding the osdmap before the monitor bootstraps using the wrong address.

i will try to come up with a cleanup to make the override more explicit. and probably remove the "mon_sync:temp_newer_monmap" value once the monitor is bootstrapped with the correct rank and address.

@dvanders
Copy link
Contributor Author

it was introduced back in https://tracker.ceph.com/issues/44076, and its purpose was to break the respawn loop of the monitor whose addresses changes in the latest map by overriding the osdmap before the monitor bootstraps using the wrong address.

Correct, and that previous fix only covered the case where the mon db was existing for awhile (i.e. monmap:last_committed exists).
This new PR covers also the case where there is a respawn loop for a mon starting with an empty db (e.g. after reinstalling the OS).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants