On Wed, 11 Jul 2018, John Spray wrote: > Hi all, > > In discussion with Noah about using the inter-module calls[1], we got > to thinking about whether we now need a dependency concept between > modules. > > However, maybe we can avoid doing full-on dependency management -- > when there is a hard dependency, it's generally on an "infrastructure" > type module (like "crash" or "progress"). Since those modules don't > e.g. depend on external libraries or do external IO, it would be > possible to simply always enable them on all systems. > > This would also simplify: > - upgrades, where currently people don't get the new modules unless > they explicitly enable them. > - documentation, where functionality in an "always on " module > wouldn't need to be caveated with instructions for enabling it, as the > user wouldn't even notice that the functionality was coming from a mgr > module. > > So, any thoughts on this? Should we add an "always on" flag to > MgrModule? If we have it, is that going to be sufficient to avoid > needing any more complex dependency management between modules? The idea that you can't disable the module is rubbing me the wrong way. On alternative would to be to enable the modules the first time they appear--i.e. when you upgrade. That would require a bit of state in the mon to keep track of which ones were auto-enabled in the past so that it is only done once. The first time the module claims to be 'on by default' the mon will enable it. Alternatively, a config setting could list the 'always on' modules. That means the default value could be changed by us on upgrades etc. The danger is that the user might override it for some reason and then miss out on new goodies on upgrade. 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
