On Wed, 26 Jan 2005, Christopher Browne wrote:

> Darcy Buskermolen wrote:
>
>> On January 25, 2005 11:02 pm, Steve Simms wrote:
>> 
>>> - "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.

Could it be set up such that if Perl is present, they're installed with a 
"make install", and not otherwise?  (Or, if a --with-perl option, or 
something to that effect.)

> If they are put in some subdirectory, e.g. $PGHOME/share/slony1/scripts, that 
> seems reasonable to me.

For the executable files, I'd like to have them in the path somewhere by 
default, or have a configuration switch that will let me put them there. 
I'm much less concerned about the library location, as long as the scripts 
know where to look.

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

Hmm, XML isn't what I had in mind.  More of a "field = value" format, 
possibly divided into sections somehow.

Ideally, I'd like to only have information that can't be pulled in the 
database in this file, which would make it simpler to store.  I don't need 
the entire cluster configuration if I can get that from the database; just 
enough to run commands.

That conflicts with the requirement that these scripts not use DBD::Pg, 
however, unless we get creative with psql or have some other way of 
connecting to the database (libpq?).

So, it might be best to drop that for now, and stick with the Perl 
configuration file, but in a known location set at "make" time.

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

On Wed, 26 Jan 2005, Josh Berkus replied:

> Interesting.  I was about to suggest building altperl as a CPAN module, in
> fact.  Now I can see how that might not be desirable.

I was also thinking about using CPAN.  If the tools are going to be 
developed in tandem with Slony releases, then it isn't really needed.  If 
we're going to separate their releases, CPAN would be a nice distribution 
method.  It wouldn't preclude downloading the tar.gz and installing it 
locally on a system where CPAN wasn't allowed.

I'd like to go with an "install it if you can" mindset rather than only 
including the lowest common denominator, so that scripts that use more 
advanced features are still available for what I would guess is the majority 
of people who have DBD::Pg available, but there's certainly enough to do 
without getting into that for the time being.

> I can see the desire, eventually, for 2 sets of tools: 1 in altperl which 
> is loosely coupled with no dependancies other than slony, and one as a 
> CPAN module that makes use of DBI, Introspector, ps and other modules.

I would imagine that the "no dependencies" version would eventually be 
rewritten into shell scripts or C.  If I were comfortable with either, I'd 
volunteer to do that.

I wouldn't want the CPAN version to require much more than DBD::Pg if it can 
be avoided -- I don't like installing modules that require 15 other modules, 
half of which haven't seen a 1.0 release.  :-)

>>> - Combine some of the scripts by logical function?  slon_start and
>>> slon_kill could be combined into slon_ctl, for example.
>>> 
>> 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"...

I could probably manage this by looking at other implementations.  Perl is 
easiest for me, as I've been writing in it every day for some three years 
now, so it's what I go with barring any reason to use another tool.

Thanks,
Steve Simms

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