Skip to content

mgr,mon: subscribe to config-key changes from mgr; maintain mgr-side ConfigMap#39504

Merged
liewegas merged 12 commits intoceph:masterfrom
liewegas:mgr-configmap
Feb 21, 2021
Merged

mgr,mon: subscribe to config-key changes from mgr; maintain mgr-side ConfigMap#39504
liewegas merged 12 commits intoceph:masterfrom
liewegas:mgr-configmap

Conversation

@liewegas
Copy link
Member

  • convert mon ConfigKeyService to KVMonitor (PaxosService)
  • allow subscriptions to config-key prefixes
  • make mgr subscribe to mgr/, device/. This results in cleaner/faster startup and allows mgr to see config-key changes made via the CLI
  • make mgr subscribe to config/ and maintain a ConfigMap
  • implement mgr_module get_foreign_ceph_option(entity, name) to get any ceph config option for any daemon (excluding mgr module options)
  • update cephadm to use get_foreign_ceph_option() instead of 'config get'

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.

cmd_getval(cmdmap, "prefix", prefix);
string key;
cmd_getval(cmdmap, "key", key);

Copy link
Member

Choose a reason for hiding this comment

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

are permissions already checked elsewhere? I'd expect those checks here

Copy link
Member

Choose a reason for hiding this comment

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

also in prepare_command()

Copy link
Member Author

Choose a reason for hiding this comment

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

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

Choose a reason for hiding this comment

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

duplicate kv:config/

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed!

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

Choose a reason for hiding this comment

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

it'd be great to get rid of raw pointers here

@liewegas liewegas force-pushed the mgr-configmap branch 3 times, most recently from b46bbf5 to be16d18 Compare February 17, 2021 17:13
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>
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')
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member

@jecluis jecluis left a comment

Choose a reason for hiding this comment

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

It looks good to me.

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants