On 05/22/2017 08:31 AM, John Spray wrote: > On Fri, May 19, 2017 at 7:25 PM, Ken Dreyer <kdreyer@xxxxxxxxxx> wrote: >> On Fri, May 19, 2017 at 12:19 AM, Tim Serong <tserong@xxxxxxxx> wrote: >>> We can't have mgr just load everything that exists (someone might want >>> to disable some modules, without necessarily uninstalling them). >> >> I'm curious why not? > > Perhaps "can't" is too strong a word, but the way it only loads > explicitly enabled modules is intentional. > > The thinking was... > 1. It's not a given that every module will be packaged independently. > That's not necessarily going to be useful in all cases -- if/when we > reach a point where some modules are so ubiquitous that we want them > everywhere, then having lots of separate packages may not be > desirable. I'm thinking back to things like the > gstreamer-plugins-good/bad/ugly packaging, and the bajillion apache > sub-packages -- as a user I usually find this stuff really frustrating > because I have a big root partition and my life is simpler if I just > pre-emptively have all the modules (but that doesn't mean I want them > all running). > 2. Which packages are installed on a system is usually something > controlled by an external tool, which tends to be different on > different sites/in diffferent products. Consequently, the exact steps > required to turn off a module are not going to be consistent across > sites. It is not a given that a support/admin person will know how to > turn off an individual package, unless they're also the person who > configured whatever orchestration tool was installing packages. What John said. I might not mind having installation of a package trigger default enablement of something (depends on the service), but I really don't like the idea of being required to uninstall something in order to disable it. In addition to the above, even if I *am* the person immediately responsible for installing packages on a system and I know what they all are, I can't necessarily guarantee that package repos are always available, or that if available their content won't change. This causes problems if I uninstall something to disable it, then later want to re-enable it. Here's a fun possible edge case: install a module, then later decide to disable it temporarily by uninstalling it. Later still, I want to re-enable it, but meanwhile updates to ceph have been released in my distro's update repo. I can no longer install the module which matches the version of ceph I have installed, and so need to upgrade my base ceph packages too in order to install the module I want to enable. > 3. The "install to enable" convention is more welcome on some distros > than others. For example, debian (I think) historically did/does this > for services, RPM distros historically didn't. Some services will be enabled by default if installed on openSUSE and SLE now. But not very many :) See https://build.opensuse.org/package/view_file/openSUSE:Factory/systemd-presets-branding-openSUSE/default-openSUSE.preset?expand=1 >> >> Ceph is already hard to configure, and "install to enable / uninstall >> to disable" would make it simpler to use. > > My preferred solution would be mon commands for toggling modules "ceph > mgr module [enable|disable] <module>", and a record in the MgrMap that > says which are enabled. There would be a bit of extra data in the mgr > beacon message for the daemons to tell the MgrMonitor which modules > are available. The MgrMonitor could also raise a health warning if > the mgr daemons have inconsistent plugins. > > The major advantage of doing that is that all the mgr daemons see the > same setting. That way, if someone enables a module on one of their > mgr nodes, they don't get a nasty shock when a failover happens and > the module is gone on the node they failed over to. > > It would also let them do it without having to go and directly log > into each of their mgr nodes to make a change (as they currently have > to do with config files, or would also have to do with package > install/uninstall or symlinks). Good idea, that's much better than my symlink thing. Regards, Tim -- Tim Serong Senior Clustering Engineer SUSE tserong@xxxxxxxx -- 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
