On Tue, Dec 11, 2007 at 06:59:40AM -0700, Serge Dubrouski wrote: > On Dec 11, 2007 1:50 AM, Dejan Muhamedagic <[EMAIL PROTECTED]> wrote: > > Hi Serge, > > > > On Mon, Dec 10, 2007 at 08:52:53PM -0700, Serge Dubrouski wrote: > > > This is a patch that I believe make pgsql RA compatible with those rules. > > > > > > On Dec 10, 2007 3:51 PM, Serge Dubrouski <[EMAIL PROTECTED]> wrote: > > > > Ok, I think I got where the problem is. Before calling "monitor" or > > > > "stop" it should check if the resource is stopped and if it is it > > > > should return 0, not 1 as it does now when called not by root. Right? > > > > Not exactly. In case a prerequisite is missing (such as, say, the > > pgctl program), the monitor and stop operations should not report > > error but that the resource is stopped. > > In case if they are missing that would mean thta PostgreSQL wouldn't > be able to start and always be stopped. So those operation will always > return the right codes.
Exactly. > But I can add explicit checks for them. Thanks, Dejan > > >The reason for all this > > is that the RA should succeed on stop and return stopped (rc 7) > > in case the software is not installed. That's common in case the > > software is installed on a shared storage, but not on a clustered > > filesystem. Or in case some nodes are never meant to run some > > resource. See for example the apache or db2 or oracle resource > > agents. > > > > Thanks, > > > > Dejan > > > > > > > > > > On Dec 10, 2007 2:54 PM, Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote: > > > > > On 2007-12-10T12:38:34, Serge Dubrouski <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Both operations include calling pg_ctl or psql. validate_all checks > > > > > > that they are set in the right way. > > > > > > > > > > /usr/sbin/ocf-tester can very quickly show whether everything works as > > > > > it should ;-) > > > > > > > > > > I can see an option to ocf-tester: --live <rsc_id> > > > > > > > > > > Which would pull the resource data from the CIB (making sure it's > > > > > stopped & unmanaged) and would try to run it where the user invoked > > > > > the > > > > > command. > > > > > > > > > > And then the GUI could call out to that script via a button. > > > > > > > > > > Wouldn't that be nice. > > > > > > > > > > > > > > > Regards, > > > > > Lars > > > > > > > > > > -- > > > > > Teamlead Kernel, SuSE Labs, Research and Development > > > > > SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg) > > > > > > > "Experience is the name everyone gives to their mistakes." -- Oscar > > > > > Wilde > > > > > > > > > > > > > > > _______________________________________________________ > > > > > Linux-HA-Dev: [email protected] > > > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > > > > Home Page: http://linux-ha.org/ > > > > > > > > > > > > > > > > > > > > > -- > > > > Serge Dubrouski. > > > > > > > > > > > > > > > > -- > > > Serge Dubrouski. > > > > > > > _______________________________________________________ > > > Linux-HA-Dev: [email protected] > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > > Home Page: http://linux-ha.org/ > > > > _______________________________________________________ > > Linux-HA-Dev: [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > Home Page: http://linux-ha.org/ > > > > > > -- > Serge Dubrouski. > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
