One of the problems we've had with running large-scale hosting systems
for StatusNet is enabling new plugins. If the plugin is not enabled,
its database tables are not checked at script time. Conversely, if it
is enabled, it may take several hours to run checkschema for tens of
thousands of sites -- during which time users might see DB errors.
A new argument to checkschema lets it pre-load one or more plugins
before checking the schema. This lets us prepare the plugins' database
tables before they're used in production. In a multihome environment,
this can be combined with tags to gradually roll out a new plugin.
In the config file, a stanza like:
$site = Status_network::getFromHostname(...);
if ($site->hasTag('fooenabled')) {
addPlugin('Foo');
}
...will only enable the plugin on certain sites. Meanwhile, a bash
script like this should gradually enable the plugin:
# For all sites...
for site in `php allsites.php`; do
# Update the schema for the Foo plugin
php checkschema.php -s$site.wildcard -xFoo;
# Enable the Foo plugin
php settag.php -s$site.wildcard fooenabled;
done
An error in the domainstatusnetworkinstaller cleared the tags table,
losing any information about sites on the service. (We discovered this
in production on StatusNet OnDemand). Conjunction of these factors: 1)
the installer code was using an insert()'ed object with an
auto-incrementing key, which because the statusnet.ini was incorrect,
wasn't getting updated. 2) It then called setTag() on that object,
which deletes all tags matching the id, then adds in the new ones. 3)
Because the ID was null, DB_DataObject deleted all rows in the table.
I've made a work-around that re-fetches the status_network object
based on its (unique) nickname, which gets the correct ID, which
should work for tags. Confirmed that it works. Still need to fix the
underlying problems, however.
