mgr,mon: subscribe to config-key changes from mgr; maintain mgr-side ConfigMap#39504
Merged
liewegas merged 12 commits intoceph:masterfrom Feb 21, 2021
Merged
mgr,mon: subscribe to config-key changes from mgr; maintain mgr-side ConfigMap#39504liewegas merged 12 commits intoceph:masterfrom
liewegas merged 12 commits intoceph:masterfrom
Conversation
jdurgin
reviewed
Feb 17, 2021
jdurgin
reviewed
Feb 17, 2021
| cmd_getval(cmdmap, "prefix", prefix); | ||
| string key; | ||
| cmd_getval(cmdmap, "key", key); | ||
|
|
Member
There was a problem hiding this comment.
are permissions already checked elsewhere? I'd expect those checks here
Member
Author
There was a problem hiding this comment.
they're checked in the caller at https://github.com/ceph/ceph/blob/master/src/mon/Monitor.cc#L3422
jdurgin
reviewed
Feb 17, 2021
src/mgr/Mgr.cc
Outdated
| monc->sub_want("kv:config/", 0, 0); | ||
| monc->sub_want("kv:mgr/", 0, 0); | ||
| monc->sub_want("kv:device/", 0, 0); | ||
| monc->sub_want("kv:config/", 0, 0); |
jdurgin
reviewed
Feb 17, 2021
src/mon/ConfigMonitor.cc
Outdated
| dout(10) << __func__ << " unrecognized option '" << name << "'" << dendl; | ||
| opt = new Option(name, Option::TYPE_STR, Option::LEVEL_UNKNOWN); | ||
| // FIXME: this will be leaked! | ||
| config_map.stray_options.push_back(opt); |
Member
There was a problem hiding this comment.
it'd be great to get rid of raw pointers here
b46bbf5 to
be16d18
Compare
Convert this into a normal PaxosService. This gives us (1) code uniformity and also (2) a changelog in the form of the paxos commits for recently changed keys that we can use to allow clients to subscribe to changes. For upgrades this is pretty painless: - the actual kv data is in the same place - an old mon will still see updates made by a new monitor - a new mon will still see updates made by an old monitor, but won't get a paxosservice version bump. Signed-off-by: Sage Weil <sage@newdream.net>
Allow subscription to config-key/kv data. Initially we'll send a full dump of the prefix. As changes occur, we'll send incremental diffs, unless the subscriber is too far behind, in which case we'll send a full dump again. There is a new message, MKVData, to support this. No compat issues since old clients won't subscribe to this stream unless they know how to handle it. Signed-off-by: Sage Weil <sage@newdream.net>
Include the config/ prefix (which we weren't loading before). Before we are active, we collect these changes, and then pass them to the ActivePyModules ctor. No change in functionality here, except that when we make a change from a mgr module, we'll (1) put it in our local cache store, (2) send the mon command to set it, and (3) get a notification that updates the same value. Since this whole process is synchronous (see ActivePyModules::set_store()), and the notification will generally arrive *before* the command ack, there is no change in behavior. If the mon cluster is not yet pacific, we still need to load kv values the old way. If it's a mixed-mon cluster (and, e.g., our current mon has the feature but not all of them do), we'll get this data both ways, but no harm is done. Signed-off-by: Sage Weil <sage@newdream.net>
The const Option* needs to remain alive only until the next clear(). Keep the reference in ConfigMap and clean it up then. Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Sage Weil <sage@newdream.net>
Fetch a config value that applies to an arbitrary daemon in the cluster. Initial implementaiton is not very efficient, but it is better than a round-trip query to the monitor. Note: this currently excludes mgr/ options (which should hopefully not be of interest on other daemons!). Signed-off-by: Sage Weil <sage@newdream.net>
…n command Signed-off-by: Sage Weil <sage@newdream.net>
PyModule::config_prefix is "mgr/", so this has no effect. Signed-off-by: Sage Weil <sage@newdream.net>
This code is working with config option names, not config-key keys. Signed-off-by: Sage Weil <sage@newdream.net>
The prefix for module kv store is "mgr/", but it is not *config* (which lives under /config/mgr/...). Rename the constant. Signed-off-by: Sage Weil <sage@newdream.net>
be16d18 to
3bafb5e
Compare
neha-ojha
reviewed
Feb 17, 2021
Comment on lines
+514
to
+517
| # complete mon upgrade? | ||
| if daemon_type == 'mon': | ||
| if not self.mgr.get("have_local_config_map"): | ||
| logger.info('Upgrade: Restarting mgr now that mons are runnig pacific') |
Member
There was a problem hiding this comment.
I seem to recall we had some issues in the past due to which the mgr needed to be upgraded first, wondering if that doesn't hold any longer.
2b5878f to
8ea3451
Compare
If we are upgrading to pacific, we need to restart the mgr *after* the mons have a pacific quorum so that they can get the kv subscriptions. Signed-off-by: Sage Weil <sage@newdream.net>
8ea3451 to
4d7dd00
Compare
This was referenced Mar 22, 2021
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For the most part there are no upgrade/downgrade compat issues here, except that a new mgr may be running against a mon cluster that doesn't (all) support kv subscriptions, in which case it still needs to do the old slow thing of fetching all of the config-key values individually.