On Fri, Jun 2, 2017 at 2:41 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > 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'?) Yes, I think so. We'll have cases like this where the commands are obviously module-ish, and other cases where modules want to expose first class/top-level things, so leaving it up to the module to put its own name at the start seems like the way to go. John > > 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
