`ready?` solved the problem of Puppet trying to configure resources before the cluster was actually ready to accept commands.

This would cause your Puppet run to fail, dragging loads of dependencies with it. In cases where Puppet first installs Pacemaker and continues to configure it, the run would contain loads of errors. That's for sure not what you want, which is why `ready?` was introduced I imagine, and it did solve that problem. However, it also caused your Puppet runs to be annoyingly long, especially with lots of Pacemaker resources to check. That caused problems for me, which is why I made this fix. Global variables should be used with care I agree, but they are alright for global state, and cluster availability should be one. The test failed because it didn't model the use case very well, which is why I modified it to be more realistic.

Removing the `ready?` would introduce more problems than the "style fix" it would solve in my opinion. Example: we configure our boxes to configure themselves with Puppet after a bootstrap. Sometimes dependency problems arise, e.g. network or other facts which are outdated, so we need multiple Puppet runs. Using the `--detailed-exitcodes` option we have a script to do Puppet runs until no changes happen anymore or fail after x unsuccessful attempts. Removing the `ready?` would cause multiple failed Puppet runs, which i.m.o. is worse than waiting for the cluster to become available.

Please elaborate on how you see this as surprising in real usage, what problems do you envision?