dcache: alarm service -- change default db to rdbms

module: dcache

Currently the default database plugin is the datanucleus xml adapter.  This was perfectly fine when the alarm server was originally conceived of, because the client end was only sending alarm events, so the load was small.  Subsequently, we re-implemented the service to be a general log message receiver, with the level of events both sent and filtered on the server end being totally configurable.  Hence it is now possible to fill up the xml store very quickly if the event level is set below warn.  The slowdown for all queries (since it does not seem the XML plugin is capable of optimizations) is quite noticeable, and the page takes a bit to load.

It thus no longer makes sense to set the default database for alarms to xml.  This option is still available for those who do not intend to send anything but error or warn level events to the service, but our out-of-the-box recommendation should be rdbms (postgres), even if it requires the one additional setup step of creating the db (as one does for chimera, dcache and billing).

Target: master
Committed: f008530f35fecc4726a40c42e5e2ca002a38d3a2
Patch: http://rb.dcache.org/r/5553/
Require-notes: yes
Require-book: yes
Request: 2.6
Merge-req:
Acked-by: Dmitry

RELEASE NOTES:
BOOK:

The default values for alarms.store.db.type has been changed from "xml" to "rdbms".  This is done so as to accommodate the likelihood that warn messages (the default remote logging level) will accumulate but will not degrade the performance of the alarm queries or the loading of the alarms table.  The xml option is still available at the discretion of the admin.  Remember that the alarms database must be created as you do for billing, dcache, etc., before booting the alarmserver domain.  Concomitantly, the default value for webadmin.alarm.cleaner.enabled has been changed from true to false, as the daemon which cleans out old entries is not essential when using rdbms.