1460 enhance redhat puppetmaster init.d script to easy start puppetmaster as a mongrel cluster If you'd like to run puppetmaster in a mongrel cluster you have to start X instances of puppetmaster with servertype set to mongrel. With this patch you can add more than one port to the sysconfig file and puppetmaster will automatically be started with severtype set to mongrel. You can now even specify an alternate port in the sysconfig file on which puppetmaster should be run as webrick based server. See sysconfig file for more documentation. 2008-07-29 0 0.24.5 red hat init script mongrel cluster mongrel_cluster Tue Jul 29 10:09:18 +0000 2008 Mon Oct 20 23:38:34 +0000 2008 Fixed #1460 - enhance redhat puppetmaster init.d script to easy start puppetmaster as a mongrel cluster Mon Oct 20 23:37:56 +0000 2008 commit "c202da":http://github.com/duritong/puppet/commit/c202da54da409e08efb6225e2190d465bd481ca4 pushed: "ticket/1460":http://github.com/duritong/puppet/tree/ticket/1460

If lutter is a happy camper then I'm fine with this.

jamtur01 wrote: > If lutter is a happy camper then I'm fine with this. David?

I'd like to see that in 0.24.6, this (old) patch will probably fail due to some newer patches (like #1646) but I can rebase my work to the latest version of the branch.

immerda - please re-base but you'll need to be quick...

James asked me to summarize what we discussed on IRC yesterday: * there's no need to introduce PUPPETMASTER_PID_DIR as a variable in sysconfig * the way RETVAL is accumulated (RETVAL=$? || $RETVAL) is wrong; it needs to be 'ret=$?; [ $ret != 0 ] && RETVAL=$ret' * make sure that 'status' still works and lists all the instances in the multiport case (similar to 'service nfs status')

lutter wrote: > James asked me to summarize what we discussed on IRC yesterday: > > * there's no need to introduce PUPPETMASTER_PID_DIR as a variable in sysconfig > * the way RETVAL is accumulated (RETVAL=$? || $RETVAL) is wrong; it needs to be 'ret=$?; [ $ret != 0 ] && RETVAL=$ret' > * make sure that 'status' still works and lists all the instances in the multiport case (similar to 'service nfs status') I rebased the patch and addressed the problems you mentioned in commit: commit "32f40e9":http://github.com/duritong/puppet/commit/32f40e933cfd1d109d2fc93fd14e811a93b2fa3b the commit have been pushed to "tickets/0.24.x/1460":http://github.com/duritong/puppet/commits/tickets/0.24.x/1460 One thing that appeared on the same time on the mailing list is, that this feature enhancement won't work on rhel/centos versions prior to 5. I have addressed that in a comment where the settings are done to start puppetmaster as mongrel cluster. The main problem for this issue is on both sides (rhel/centos rc-functions and puppetmaster): - every puppetmaster instance has to be started with a different pid file. otherwise the cluster setup won't work and only one puppetmaster instance will be started. - rc-functions prior to rhel/centos 5 doesn't support calling killproc (to stop) and status with a specific pidfile. Therefor we're not able to address each instance of the cluster directly over its pidfile. And as rc-functions assumes only one daemon to be started at once, we have no possibility to address the different instances with the rc-functions. I dunno if we'd like to introduce such a version incompatibility, on the other side I think most people are running puppetmaster in a mongrel cluster and therefor an init.d-script which is aware of this possibility would be nice. An option would be to provide a different init-script for the different versions. so an old only single instance script for versions prior to 5 and the enhanced script for versions >= 5. On the other side I would see the comment in sysconfig to be sufficient. But I don't know the packaging rules for fedora/rhel for such cases. I would therefor propose we'll introduce this patch into 0.24.6. However I'm not the person to decide that, so I'll leave this ticket on "Needs design decision". But I think that we can talk about that even if the patch is already in some rc for 0.24.6 and still can remove it later, not?

Are you sure this is based on 0.24.x? Looks like it's branched from master to me.

immerda wrote: > > I rebased the patch and addressed the problems you mentioned in commit: commit "32f40e9":http://github.com/duritong/puppet/commit/32f40e933cfd1d109d2fc93fd14e811a93b2fa3b the commit have been pushed to "tickets/0.24.x/1460":http://github.com/duritong/puppet/commits/tickets/0.24.x/1460 Looks good; two small questions/suggestions: (1) There's a lot of uses of the expression <pre> [ -n "$PUPPETMASTER_PORTS" ] && [ ${#PUPPETMASTER_PORTS[@]} -gt 1 ] </pre> it would be more readable if you set somewhere at the beginning of the file <pre> [ -n "$PUPPETMASTER_PORTS" -a ${#PUPPETMASTER_PORTS[@]} -gt 1 ] && multiport=yes || multiport=no </pre> and in the rest of the script just did tests like '[ $multiport = yes]' (BTW, the use of && in the test works, but it's a little ugly) (2) Did you check if the stock status command does anything useful in the multiport case ? It works for nfs - I don't have an issue with puppetmaster_status, but less code is always better ;) > One thing that appeared on the same time on the mailing list is, that this feature enhancement won't work on rhel/centos versions prior to 5. I have addressed that in a comment where the settings are done to start puppetmaster as mongrel cluster. Yeah, that's quite a headache; but I think documenting that on RHEL < 5 you're SOL is good enough. I don't want to get into the game of shipping different init files and the ensuing packaging ugliness. If somebody wants this badly enough for RHEL < 5, they are more than welcome to send a patch ;) All in all, I think this is ready to be checked in, though I really would like to see (1) addressed.

jamtur01 wrote: > Are you sure this is based on 0.24.x? Looks like it's branched from master to me. ups yeah you're right. sorry for that, I'm somehow I mess this branch stuff always a bit up, let's put 0.25 out :P. But yeah for sure this is for 0.24.x I took now the 0.24.x branch for the new commit. lutter wrote: > [...] > Looks good; two small questions/suggestions: > > (1) There's a lot of uses of the expression > [...] > it would be more readable if you set somewhere at the beginning of the file > [...] > and in the rest of the script just did tests like '[ $multiport = yes]' > > (BTW, the use of && in the test works, but it's a little ugly) ok, I addressed that in the new commit. > (2) Did you check if the stock status command does anything useful in the > multiport case ? It works for nfs - I don't have an issue with > puppetmaster_status, but less code is always better ;) hmm what exactly do you mean with stock status command? Anyway I did some tests with the status command: I killed for example one instance and the exit code of the status cmd was then != 0 and it also reported the right process as not running, so I assume it to be working as a status command should?. > > One thing that appeared on the same time on the mailing list is, that this feature enhancement won't work on rhel/centos versions prior to 5. I have addressed that in a comment where the settings are done to start puppetmaster as mongrel cluster. > > Yeah, that's quite a headache; but I think documenting that on RHEL < 5 > you're SOL is good enough. I don't want to get into the game of shipping > different init files and the ensuing packaging ugliness. ok then I'm happy. :) > If somebody wants this badly enough for RHEL < 5, they are more than > welcome to send a patch ;) :) > All in all, I think this is ready to be checked in, though I really would like to > see (1) addressed. pushed "0e03ffe":http://github.com/duritong/puppet/commit/0e03ffe48a43cb6f22eb77497ae3042a4a97abdf to "tickets/0.24.x/1460":http://github.com/duritong/puppet/tree/tickets%2F0.24.x%2F1460

This is still branched from master.

jamtur01 wrote: > This is still branched from master. hmm this time I did for sure: git-checkout origin/0.24.x -b ticket/1460 as well have a look @ the changelog for example: http://github.com/duritong/puppet/tree/tickets%2F0.24.x%2F1460/CHANGELOG this is imho definately not from master.

rebased to james' 0.24.x branch

Pushed in commit:"b53509b4538cf581d2d306b43c11f729ba9a2568" in branch 0.24.x