Darcy Buskermolen wrote:

>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.
>  
>
If they are put in some subdirectory, e.g. $PGHOME/share/slony1/scripts, 
that seems reasonable to me. 

They're not all that big, and installing them, by default, in some 
quasi-standard spot will make life easier for those assembling packages 
for Linux/BSD distributions.  THAT is the case for us to optimize for; 
if we make life easy for those building RPM or .deb packages, that will 
increase usage of Slony-I and its components many more fold.

>  
>
>>- 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.
>
>  
>
It would be sort of neat to have a quasi-standard way of describing 
cluster configuration.  But I wouldn't want to add complexity for this 
particularly when we don't yet have a "second tool" that knows how to 
read it. 

- I'd hate to create an XML format that's liable to be half-baked;
- I'd hate to create some scheme that would encourage needing to 
integrate in a Yacc parser;
- My "marginal" preference would be to use S-expressions, but that would 
need still another parser for Perl-based usage

And I hate solving for a multilingual answer where we don't actually 
have a problem yet...

>>- 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.
>  
>
I'd favor the location in the area where other Slony-I components are 
installed, e.g. - alongside the things put into the PostgreSQL install tree.

>>- 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.
>
>  
>
I like that.

>>- "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.
>
>  
>
It's coming along...

>>- 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)
>
>  
>
I think this one fits more into adding a "cookbook" to the admin guide 
which takes some more-or-less common tasks and outlines how to do them.

What I would _oppose_ for these scripts is the notion of trying to make 
the scripts too terribly much smarter, e.g. - by integrating in DBI or 
Pg modules so that they query database state.  Part of the design of 
these scripts involves them NOT having tight integration with the 
databases; they are consciously loosely coupled so that they can "play 
well" in environments where you get Perl provided but where you _can't_ 
add extra CPAN modules.  In particular, I am thinking of the UNIX(tm) 
systems: AIX, Solaris, HP/UX, and such.  We're running AIX and Solaris 
in hosted environments where we don't get to install extensions, and 
Pg/DBI would be examples of extensions.

You may notice some Perl scripts elsewhere that reference Pg; note that 
those scripts are quite separate from the "altperl" admin tools.  The 
"hosted environment" reason is why that is.

>>- 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.
>  
>
Sure, that seems reasonable.  In CVS HEAD, you get to specify where the 
PID gets stored when a slon is started, so it would make a lot of sense 
for there to be a slon_ctl that specifically looks for this.

I'd tend to think slon_ctl should be implemented as a shell script as 
opposed to Perl to be consistent with "tradition"...

>  
>
>>- 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.
>
>  
>
Renaming the scripts certainly seems reasonable to me.

The names initially given did not involve much agonizing on my part, so 
I won't agonize much if there is a consistent naming change.

>>- 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.
>
>  
>
I have a script recently added to tools, test_slony_state.pl, which I am 
running daily on our clusters to send output to our DBAs.  They are 
already suggesting ways to improve it with regards to having it try to 
point out problems

>>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?
>>    
>>
For my part, I'm more than happy to see Steve's proposal and his 
contributions to the tools. 

I quickly hacked up the initial set of tools which means I don't even 
really perceive when they are a little inconsistent here or there.  
Steve has been cleaning that up nicely.

It means I can apply my attentions elsewhere, which is a win.  And it 
means that the tools are improving via having more peoples' thoughts 
going into them, which is no bad thing.