Getting rid of 'ready?' would be very nice, sure. If the Pacemaker service was fully up-and-running when the "start" of the init script finishes this would even be quite easy, I think that's the place where this could be solved. Haven't looked into why this is, but I'm assuming the well-talented Pacemaker authors had their reasons to make it as is. My guess is the problem's a more difficult one, as Pacemaker only configures the cluster but doesn't do the communication bit. And that communication stack can differ quite a bit, e.g. I'm using CMAN, which itself configures Corosync. Pacemaker has to "wait" for all these things to start before being able to configure anything. But currently you can't count on Pacemaker being up-and-running when you started the service. A solution is the 'ready?' function, it does what it needs to do, but you can surely call it a kludge. Not defending it, but I don't carry any hatred against it either as long as it just works. 

An alternative could be to modify Pacemaker's init script to do what you want if that's even possible and push it upstream and wait for them to include it, or overwrite the init script from the Puppet module for even more hairyness. Neither are practical.

The @resource[:cib] lines you mention seem copy paste in the original, but I didn't feel the need to refactor this in the common part. No specific reason why, just didn't bother. Also keep in mind you need to access the cluster at 2 times currently: once when prefetching and once when flushing. Retries won't even be needed if the service was started correctly: Puppet would error out and that's what you want in that case anyway. But currently we're not in that situation I'm afraid.