I've updated the pad at http://pad.ceph.com/p/config After thinking about this a bit more, I think we may need to abandon the idea of a pure ceph.conf-less world. Lots of people already have tooling around ceph.conf, getting rid of it will be an awkward process (even for a one-time upgrade), and I'm not sure we can eliminate it entirely anyway since many options affect the bootstrapping phase, authentication, and so on. Instead, I'm currently partial to giving processes a more nuanced view of their config based on where the value comes from. A single option may include 1- a default value (compiled in) 2- a value from the mon 3- a value from ceph.conf 4- a value set via command line, 'ceph tell', 'ceph daemon ... config set ...', etc. We would always use the highest-priority value on that list. This means that ceph.conf can override the mon, just like a command-line argument overrides ceph.conf. On the flip side of this, all of these values are also reported to the mgr and tracked along with the other daemon state. So regardless of where config values come from, it is all still visible via the CLI, GUI, or whatever else. Further, we can then make the GUI (or CLI or whatever) act on that information to, say, - assimilate ceph.conf values into the mon so that ceph.cong can be removed/abbreviated (i.e., the upgrade/transition path to centralized config) - see override values set via cli (i.e., in gui) - clear override values (i.e., ceph tell <daemon> config rm <name>) - surface a HEALTH_WARN if a CLI or 'config set' override has been set on one or more daemons (so the operator knows the running config is not persistent). - surface a HEALTH_WARN if a mon option is overriden by a daemon's local ceph.conf file. Notably, the user can also do nothing and the cluster can continue to operate as it always has. The mgr will still have the new visibility into running daemon options, so the GUI experience will still be consistent--they just won't be able to change configs centrally (or rather, those settings won't have any effect if old ceph.conf's override them). I think Kyle's revision history suggestion is a great one. I don't have any bright ideas about how this should be managed on the mon side yet, but I agree that it is an important function and should be baked in from day 1. Thoughts? 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
