On Fri, 2 Jun 2017, John Spray wrote:
> >> Assuming we roll back the change that prefixed every key with the
> >> daemon name, modules are free to do their own prefixing for any
> >> settings that they want to be per-daemon. To enable it we just need
> >> to make sure the module has a way of finding out the name of the
> >> daemon where it's currently running.
> >
> > The reason why it's there now is that (almost) every config key we've used
> > so far need to be able to be mgr-specific. Do you have an alternative
> > proposal (besides trying mgr/$id/$module/$option or
> > mgr.$id/$Module/$option and then mgr/$module/$option)?
>
> My proposal is mgr/$module/<whatever the module wants>
> ...which in practice for TLS certs would be mgr/$module/$id/$option
>
> Then, enable the modules to retrieve their current daemon's config by
> giving them a function that tells them the name of the currently
> running daemon.
That sounds fine to me.
> One day, it would be nice to have modules consume their config from
> the new key/val config store on the mon. Then, they could just have
> whatever level of cleverness was available for configuration in
> general for those settings, and the current "get_config" stuff would
> be exclusively for persistent state as opposed to user-input config.
FWIW my hope here was to adopt a convention here that matched what we were
going to do for config. That's why there is the global -> mgr -> mgr.x
hierarchy thing. That might be a fool's errand, though, since we
(will) have a well-defined set of config options, whereas the module
options are module-defined.
Anyway, I think the suggestion currently is for
"mgr/dashboard/x/server_addr",
"mgr/dashboard/x/server_port",
"mgr/dashboard/y/server_addr",
"mgr/dashboard/y/server_port",
"mgr/restful/keys",
"mgr/restful/x/crt",
"mgr/restful/x/key",
"mgr/restful/x/server_addr",
"mgr/restful/x/server_port",
"mgr/restful/y/crt",
"mgr/restful/y/key",
"mgr/restful/y/server_addr",
"mgr/restful/y/server_port"
?
Although I'd probably suggest also changing
"mgr/restful/keys",
to separate per-key keys, like
"mgr/restful/keys/$user",
(Also, the 'ceph tell mgr.x create_key $name' thing concerns me a bit
that it's unclear this is for the restful module. Should we have modules
prefix their commands by module name by convention where it makes sense?
e.g., 'ceph tell mgr.x restful create_key $name'?)
sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
