Do not do anything in monitor.rb recipe if there's nothing to monitor
Do not run ring-compute.rb recipe too early

If a node is both a storage node and a ring-compute node, it can't
compute the ring on the first chef-client run because the information
about devices for each storage node is not available yet in the compile
phase. Therefore, we just return from the recipe.

It will all work fine because:

 - crowbar has an explicit later chef-client run for the ring-compute
   role, that will build the rings after the disks have been found.

 - if the node is a storage node, it must have devices; if not, we raise
   an exception already. So the test to return or not from the recipe
   can rely on that information;
Do not try to run the proxy bits too early

If the rings are not present, then swift-proxy will just fail to start.

There are two cases:

 - if we're a storage node and we have no devices yet, then we know
   we're on the first pass of the crowbar orchestration for storage
   nodes, so we can just ignore the proxy bits

 - if we do not have the rings yet in the execute phase when trying to
   setup the services, then it means the ring-compute node didn't push
   them yet or we didn't manage to pull them yet. Since we know that
   swift-proxy will fail without the rings, there's no point in doing
   anything. For setting up swift-proxy, we instead rely on the chef run
   after the one for ring-compute that crowbar will orchestrate.

The last case can happen for various reasons, but the most likely one is
having the periodic chef-client run occur on the swift-proxy node before
the crowbar chef-client run occurs on the swift-ring-compute node. We
know that crowbar will run chef-client on the swift-proxy node after the
rings have been computed, so we will have the rings and a chance to
start swift-proxy later on.

https://bugzilla.novell.com/show_bug.cgi?id=872518
Do not try to run the dispersion bits too early

If the dispersion node is also a storage node or the ring-compute node,
then the dispersion recipe will be run too early, before swift is
totally setup. We detect these cases to not proceed with the dispersion
recipe.
ha: Do sync marks for pacemaker resources only when needed

It makes no sense to do the sync marks when we won't create the
resources.
Improve check for no disks on storage node

Some disks that we mark as "to use" are actually ignored later on if
they already have a partition not created by us. So we should check for
the disks after this.