On Wed, 10 Jan 2018, Jesse Williamson wrote: > On Mon, 8 Jan 2018, Piotr Dałek wrote: > > > * WARNING: "osd objectstore" is deprecated, you should change your config to > > use "osd/objectstore" instead. > > If there is a 1:1 correspondence between names, I like this idea. I think it comes down to this. We have these two options (at least): 1. Current branch mgr/$module/$option = $value # mgr module settings, pretty freeform dm-crypt/osd/$uuid/... = ... # dm-crypt secrets config/$option = $value # global config/$type/$option = $value # by type config/$type.$id/$option = $value # by daemon config/.../$type:$val/$option = .. # filtered by crush, osd class - config stuff is very clearly separate - everything not under mgr/ dm-crypt/ config/ above is available for other uses 2. Combined schema mgr/$module/$option = $value # mgr module settings, pretty freeform dm-crypt/osd/$uuid/... = ... # dm-crypt secrets global/$option = $value # global $type/$option = $value # by type $type.$id/$option = $value # by daemon $type[.$id]/$ctype:$val/$option = # filtered by crush, osd class This would result in keys like mgr/dashboard/... mgr/debug_mgr mgr.x/debug_mgr global/* osd/* mds/* osd.123/ and so on. - everything exists closer to the same level, looks more unified - config stuff *still* has distinct prefixes, so we can tell what is a traditional config option and what is not - everything outside of $daemontype and 'global' prefixes (and dm-crypt) is still available for other uses. I'm ignoring the part where we start renaming options (osd_data -> osd[.123]/data) -- that is an independent problem to solve IMO. The only real technical downside I see to #2 above is that the laod_config() method in ConfigMonitor has to scan more config-key keys than it did before, and be smart enough to ignore mgr/$string/$option keys where $string doesn't have a '$this:$that' mask format (should be okay since mgr modules can't contain : in the name). What does everyone think? sage
