I'm starting to become comfortable with the tools/altperl scripts as a way 
to control slon and slonik, and I think that if we can address a few 
limitations that they have, they could form the basis of a standard set of 
command-line tools for Slony administration.

Here are some of the issues/enhancements that I would like to focus on, in 
no particular order:

- "make install".  There doesn't seem to be any included way of
   installing these tools.  On my machine, I'm still running them from
   /usr/local/src/slony-1.0.5/tools/altperl.

   I'd like to see the administration tools be installed when "make
   install" is run, in the same directory as slon and slonik.  Preferably
   when Slony's "make install" is run, but I'll take a separate "make
   altperl-install" if that's too much to ask.

- Configuration file revamp.  Currently, the configuration file is a Perl
   script itself, and is assumed to be in the current working directory,
   though it would also work if it were anywhere in Perl's list of library
   paths.  The --config option I've been adding makes it possible to
   specify a different configuration file from the command-line, but that is
   a pain to include with each command.

   Instead, I'd like to have a configuration file akin to the postgresql.conf
   file, perhaps in the same directory, or some /etc location.  This would
   allow other tools (including non-Perl tools) to use the same configuration
   file down the road.

   This file could be set up to have information for one cluster, or for
   many.  I'm not sure how the file would look in the case of the latter, but
   different clusters could be specified to scripts by giving a --cluster
   command-line option, which would be unnecessary if there was only one of
   them.  If the configuration file only supported one cluster, we would have
   to give a different --config option for each cluster instead.

- Location of slon-tools.pm.  Like the configuration file, this library
   needs to either be in the current working directory, or somewhere in the
   Perl library path.  Instead, I think it should be given a particular
   location in the slony install path (libdir, perhaps?), and have the
   scripts reference that location when they're installed.

- Location of Perl.  Same issue -- the scripts are currently set up in a way
   that doesn't work on Red Hat, at least.  A "make" (or some other
   configuration tool) should set the #! line in each script to the
   appropriate Perl path for that machine.

- "store node" script.  This doesn't seem to exist at the moment.

- Easier set creating.  Currently, this is fairly involved, requiring a list
   of tables to be included in a Perl configuration file.  I'd rather just
   pass them all on the command line, or using STDIN.

   Additionally, I'd like to have TABLE_ID and SEQUENCE_ID auto-determined.
   This would involve a database connection, but we already have everything
   we need to make one, and it would save a monotonous and possibly
   error-prone step.

- Script to add table to existing set.  This seems common enough and simple
   enough that a script could handle it.  Create set with new table,
   subscribe, merge.

- Combine some of the scripts by logical function?  slon_start and slon_kill
   could be combined into slon_ctl, for example.

   My idea behind this is that I wouldn't want to double the number of
   files in /usr/local/pgsql/bin if that's the install path for the Slony
   scripts.

- Rename the scripts during "make install".  I'd like to get rid of the
   ".pl" when they're installed, so that if someone later converts them to C,
   no change is necessary.  It's also somewhat redundant if they're
   executable and in a /bin directory.

   For the scripts that don't start with "slon_", I'd like to consider
   alternate names that would make it clear that they're Slony-related,
   though I don't necessarily like the idea of having them all start with
   slon_, either.

- More configuration-listing and status options.  Particularly for sets.
   These would be scripts that read and report from the database, rather than
   the configuration file.


That's more than enough for one E-Mail.  If you're still reading this, thank 
you.  :-)

Some of these are more vital than others, in my opinion, but if we were to 
implement all of them, I think we'd have a very good set of tools that would 
make it much easier to administer Slony.

Comments?  These thoughts are all based on my experience using these tools 
and trying to get Slony working and maintainable in my environment -- I have 
no idea if they'd be practical for anyone else.  What changes would you want 
to make for this to work in your environment?

Thanks,
Steve Simms

--
Steve Simms <steve at deefs.net>
http://www.deefs.net