On Wed, Jul 11, 2018 at 3:46 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > 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. Why? It sounds like these are modules in the sense that they use the module APIs, but they're still part of the manager's infrastructure that users need to leave on if they want sane behavior. We shouldn't constrain ourselves by trying to support and test bad configurations just because we are taking advantage of modular development! -Greg > > 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 -- 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
