On Wed, 11 Jul 2018, Gregory Farnum wrote: > 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! Yep, I buy that! +1 from me. :) sage > -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 > > -- 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
