On Wed, Jan 18, 2012 at 5:47 PM, Daniel Nichter <[email protected]> wrote: > Walter, > > Le 16 janv. 2012 à 12:23, Walter Heck a écrit : >> On Mon, Jan 16, 2012 at 20:26, Daniel Nichter <[email protected]> wrote: >>> My one big question concerns the reasoning in item #13: should plugins be >>> "all on" by default, or "all off" requiring the user to turn on what they >>> want? I tend to think "all on" because most plugins only do one thing so >>> if the user adds it, they want it to be working now. The argument for "all >>> off" is in cases like syslog which do multiple things, or perhaps query_log >>> which, if configured badly, may come on and start hammering the disk. I >>> think the 95% case is "all on". What do you think? >> >> Couldn't it be done much like certain packages in debian? The package >> is in full configged shape, but you have to set a param in >> /etc/default/$pkgname to from disabled to enabled in order for it to >> actually work when started. If you leave it at disabled, you will get >> a message when you invoke the /etc/init.d/$pkgname script. >> That allows the developer to roll the package out with a sane >> configuration, but the user won't be surprised with new functionality >> without taking actual manual action. > > That's a good idea. Henrik has mentioned something similar to me: requiring > that each plugin provide a config file for itself.
Actually, I don't think this is the same thing as what Walter proposes. My opinion is that plugins should be on by default when installed, and user would not need to edit anything (when feasible). Let me explain: There is a difference if you - start drizzled directly from bzr repo (make; drizzled/drizzled) - make install - install a binary tar ball (essentially someone else did make install) Note: This is not currently provided - install RPMs or DEBs With RPMs and DEBs we provide a separate installation package for each plugin. Here the assumption is that if you install a plugin, you want to use it, so it should load without further action. (Btw, distributions differ on this point, but at least Ubuntu has this approach also to drizzled itself: If you install a server, they assume you want it to be running and it will be configured to start at boot. I think Red Hat does the opposite: they think nothing should be running that a sysadmin didn't explicitly set to start.) So to make all plugins load by default, our DEBs and RPMs ship with a /etc/drizzle/conf.d/pluginname.conf which contains a line plugin-add=pluginname. (This needs to be moved from the RPM/DEB scripts into the plugin sources. See lp:~hingo/drizzle/drizzle-integrate-packaging-rpm and support-files/rpm/SOURCES) Otoh for a make install or binary tar ball scenario this doesn't work. In this case the user installs everything (that was built), but it doesn't mean he wants all bells and whistles to be running. Which plugins load by default and which don't, is determined by their plugin.ini files and the user can override this at build time. *** Then to your original question. For RPMs and DEBs, when installed, plugins should be on by default and this is enabled by the configuration file plugin.conf installed into /etc/drizzle/conf.d/pluginname.conf. If they cannot work without explicit configuration (auth_ldap really needs to connect to a ldap server to work) then they must fail gracefully. An admin can then enable them via dynamic variables like you describe. If they cannot fail gracefully (plugin does not adhere to your last requirements, which currently is all plugins not written by yourself), they must not be configured to load by default. Otoh for the make install case it doesn't make sense to say that *all* (really, all of them) plugins should load by default. For instance you probably don't need both rabbitmq and zeromq support, and you certainly don't want to load all auth plugins at the same time. Hence, for both of the above it means that load_by_default in plugin.ini determines whether a plugin loads when there is no option passed via a .conf file or command line. The plugin.ini value is determined by the plugin developer. It can be overridden at build time with configure option. henrik -- [email protected] +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
