This discussion is long so I'll rephrase some stuff up top here. So these plugins,
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 (?) are in question: should we enable them by default? if yes, what is sane default config? First let say that once all the plugins become fully dynamic, then all these plugins should be able to be loaded without stopping Drizzle, even if the config is very minimal or NULL (i.e. no server hostname), because they can be configured dynamically. So, as for default functionality and default configs: auth_http (server) auth_ldap (server) memcached_stats (server) rabbitmq (?) zeromq (?) slave (config) ^ Loads but doesn't work because there's no sane default for a server, but once dynamically set, they start to work. filtered_replicator (what to filter) regex_policy (who to allow to what) ^ Default: allow everything (no restrictions), but can be changed dynamically. logging_gearman (thresholds) logging_query (thresholds) query_log (thresholds) ^ Default thresholds: 10s or something similarly large to prevent initial flooding, but (as always), can be reconfigured dynamically. transaction_log (?) ^ Log off by default (to prevent unnecessary disk activity) but make it dynamic. syslog (multiple plugins) ^ This is a problem that I'll address in another email. The big challenge in that list is slave which currently reads a config file. It should be possible to start Drizzle with slave enabled, but no config, and then config and connect to the master dynamically. After all, MySQL can dynamically re-connect to or change the master. I'm not sure if the slave code is amenable to this requirement, but it must be made amenable else replication will suffer a serious blow to usability. So in summary: *every* plugin should be able to be loaded with only --plugin-add=PLUGIN (i.e no prevent Drizzle from starting). Granted, many plugins, like the ones above, won't work just by loading them because they need some config, so either 1) there will be a default config and/or 2) the user will be able to dynamically config the plugin from within Drizzle. -Daniel Le 22 janv. 2012 à 14:20, Henrik Ingo a écrit : > On Sun, Jan 22, 2012 at 8:52 PM, Daniel Nichter <[email protected]> wrote: >> 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. >> > > The above are obvious. InnoDB of course needs to be enabled by default :-) > > >> 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 (?) >> > > I kind of disagree with this list. We should have a higher ambition > level and strive to default enable as much as possible. (Compare with > InnoDB, in practice user will need to configure it, but it still ships > as enabled with some defaults.) > > Let's add that in the above also zeromq, rabbitmq and slave will need > a server. So we cannot enable them since we cannot magically know the > hostname/address for that configuration. This much is obvious. > > For most of the others it would be possible to supply reasonable > defaults and have them enabled: > > filtered_replicator: default can be to filter nothing and replicate everything > > regex_policy: same, it can be enabled but allow everything. > > transaction_log: Ok, for this one I agree it is ok to disable by > default, otoh it could enable itself automatically when a slave > connects. > > For everything that says "thresholds", we should ship with > conservative thresholds. A good example is the mysql slow query log > that ships with a 10 sec threshold. It means only very slow queries > would be caught in it. > > ** > > If we stick to the assumption that people will mostly use debs and > rpms, and then will only install the ones they want to use (in > practice people seem to actually install everything though...) then it > follows we should do the above and strive to enable as much as > possible. This is the more consistent alternative. > > Otoh from the point of view where users compile from source, install a > binary tarball (to be provided) or just install every deb/rpm they can > find, the above are plugins that could in fact be disabled. For > instance you wouldn't ever use all auth plugins at once even if they > are installed. > > Same argument could be made for things like a slow query log. Is it > really better to default to enabled and high threshold, when we can > also provide a good default threshold (like 10 ms) and default to > disabled. > > So it seems I've reached the point where arguing for 100% compliance > is also arguing against pragmatism. You'll have to apply your own > judgement on this one. > > > henrik > > >> 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. >> > > Dynamically changing port bindings... I feel like I have to invent a > good use case for that! > > 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
