On January 25, 2005 11:02 pm, Steve Simms wrote:

Included are some of my thoughts on this, keep in mind I haven't used these 
tools, and in our infrastructure I have little use for them.

> 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.

This is not a big deal, but I'd be inclined not to have them installed via the 
standard make install target since I won;t nessarly have perl installed on 
any box but my admin station.

>
> - 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.

I've got no opinion on this eitherway.

>
> - 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.

Same as Q1.
>
> - 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.

./configure should detect perl and deal with it accordingly.  I can make this 
modification.

>
> - "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.

Well hopfully once cbb finished named objects vs ID'd this should become 
un-nessary.

>
> - 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.

Other than there is no nice way to know that the set infact has subscribed 
from the slonik interface, (or anyother easy way that i can think of)

>
> - 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.
Yes I think this is a good idea and fits with the standard of how pg does it.

>
> - 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.

My ./configure substitution will handel the rename since  sed files to deal 
with the differing perl path.

>
> - 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.

I'd like to see a whole range of status tools that interface nicely with 
existing NMC setups,  I'm hopping to have my snmp work done here in a short 
while to assist in this.

>
>
> 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
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general

-- 
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx:  250.763.1759
http://www.wavefire.com