Henrik, Thanks for the clarification. I updated https://blueprints.launchpad.net/drizzle/+spec/plugin-standards accordingly and did some research. These plugin require a config, but it's a config that's simple enough to have a default that should Just Work:
###################### ### Default Config ### ###################### auth_all auth_file auth_schema drizzle_protocol json_server logging_stats mysql_protocol mysql_unix_socket_protocol innobase memory myisam Granted, most people should reconfigure InnoDB, for example, but nonetheless I think these plugins can have a default <plugin>.conf file. On the other hand, these plugins require that the user config them: ################### ### User Config ### ################### auth_http (server) auth_ldap (server) filtered_replicator (what to filter) logging_gearman (thresholds) logging_query (thresholds) query_log (thresholds) memcached_stats (server) rabbitmq (?) regex_policy (who to allow to what) slave (config) syslog (multiple plugins) transaction_log (?) zeromq (?) The (reason why) is listed beside each. I'm not sure about the (?) plugins. For example, rabbitmq and zeromq seem to have default configs, but I'm not sure if they're sufficient. Same with transaction_log: it is configed but not enabled (it's loaded by default, but it makes itself disabled so you have to do --transaction-log.enable to actually make it work). The others surely need user configs and it is these plugins that need to fail gracefully and be able to be dynamically activated once re-configured dynamically. E.g.: set global auth_ldap_whatever=whatever; set global auth_ldap_is_active=TRUE; then the user should check either show variable like 'auth_ldap_is_active' or select is_active from d_d.plugins where plugin_name='auth_ldap'. If the config worked, it should be active; else it will still show inactive. All other modules either don't have anything to configure (e.g. default_replicator), or they're test modules (e.g. tableprototester), or they're core modules (e.g. signal_handler). That leaves us with just about 10 or so modules to make dynamic. Some like InnoDB are their own beast that I don't intend to modify. :-) Others like the protocols don't need to be dynamic (I've never seen a need to dynamically change port bindings.) So that leaves mostly any module that uses a file or external server. -Daniel Le 18 janv. 2012 à 10:18, Henrik Ingo a écrit : > 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 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
