Puppet

commit c202da
pushed: 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 the commit have been pushed to 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 the commit have been pushed to tickets/0.24.x/1460

Looks good; two small questions/suggestions:

  [ -n "$PUPPETMASTER_PORTS" ] && [ ${#PUPPETMASTER_PORTS[@]} -gt 1 ]

  [ -n "$PUPPETMASTER_PORTS" -a ${#PUPPETMASTER_PORTS[@]} -gt 1 ] && multiport=yes || multiport=no

(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 to tickets/0.24.x/1460

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 b53509b4538cf581d2d306b43c11f729ba9a2568 in branch 0.24.x