don't ignore synchronization failures by default

The "fatal" attribute of crowbar_pacemaker's sync_mark LWRP defaulted to
false, so synchronization failures effectively got ignored - the only
difference being an extra 60-second delay and a warning in the logs.

One symptom of ignoring synchronization failures is that Pacemaker
resources get created and started before setup is complete on all nodes.
This in turn causes fencing of nodes with incomplete setup when
Pacemaker attempts to start up the resources on those nodes.

It's more user-friendly if rather than fencing, the chef-client run
simply fails, since this gets bubbled up to the UI without unnecessary
failovers or interruptions to existing services running on the node in
question.

Of course, any synchronization which is advisory-only can still specify

  fatal false

in the resource block.
use crm --force to ensure start/stop in batch mode

We want to allow a resource X to be created without starting it, and
then for a group/clone Y to be created referencing X, which can
subsequently be started.  This ensures that child resources are only
started via their parent, respecting the constraints their parent needs
to impose (e.g. ordering if the parent is a group).

However in this case, changing target-role on Y causes a "Do you want to
override target-role for child resource ..." interactive prompt.  When
STDIN is not a tty, --force is required to ensure that the target-role
on the child resource.  This only works with newer versions of crm which
are patched according to:

  https://bugzilla.novell.com/show_bug.cgi?id=868697
avoid test messing with fixture

Assigning to `fixture` means that the change to the fixture can leak
out to other tests, so we assign to a temporary variable instead.
newly created resources should not be started

In Pacemaker, target-role defaults to 'Started', but we want to allow
consumers of the LWRPs the choice whether their newly created resource
gets started or not, and we also want to adhere to the Principle of
Least Surprise.  Therefore we stick to the intuitive semantics that

  action :create

creates the resource with target-role="Stopped" in order to prevent it
from starting immediately, whereas

  action [:create, :start]

creates the resource and then starts it.

Since we are honouring :start / :stop actions to determine the
target-role value, if target-role is specified via meta, it will just be
overridden anyway.  So we also deprecate direct use of target-role meta
parameter in recipes.
changes to superclasses should trigger all tests
Merge pull request #91 from aspiers/guard-superclasses

changes to superclasses should trigger all tests
pacemaker: Change default op timeout from 10 minutes to 1 minute

10 minutes is way too long and people have time to think that something
is just totally broken. 1 minute is more reasonable. And in the worst
case, an attribute can be set to change this now.
Merge pull request #86 from aspiers/sync-fatal-by-default

don't ignore synchronization failures by default
Merge pull request #95 from vuntz/op-default-timeout

pacemaker: Change default op timeout from 10 minutes to 1 minute
webui: Make drbd_enabled settable only when there are two members

Since DRBD requires two members, we force this setting to false in all
other cases.
Merge pull request #96 from vuntz/js-drbd

webui: Make drbd_enabled settable only when there are two members
Merge pull request #66 from aspiers/default-stopped-resources

prevent LWRPs starting newly-created resources by default
corosync: Add attribute to not start corosync on boot after fencing

If the node[:corosync][:require_clean_for_autostart] attribute is set to
true, then corosync will not start on boot automatically, nor through
chef-client, if the file /var/spool/corosync/block_automatic_start
exists.

On proper shutdown, one new init script (corosync-shutdown) is used to
remove that file and stopping corosync, resulting in the next boot to
have corosync starting.

This allows to not start corosync after fencing, to avoid a never-ending
deathmatch, or a fencing loop.
Expose require_clean_for_autostart attribute in crowbar
Add "automatic" option in crowbar for require_clean_for_autostart

By default, we want to use require_clean_for_autostart for a two-nodes
cluster, and only in that case. This is something that we do at the
orchestration layer with crowbar, by wrapping this value in a tri-state
attribute.
Fix potential use of undefined variable
Save ssh public keys among cluster members so they are accessible for cluster analyzing tools.

The keys must be saved into provisioner's part which will pick them
up for writing in provisioner::base recipe.
Merge pull request #97 from jsuchome/ssh_support

Save ssh public keys among cluster members so they are accessible for cluster analyzing tools.
Merge pull request #88 from vuntz/no-auto-start-on-fencing

corosync: Add attribute to not start corosync on boot after fencing
Make sbd work with partitions too, not just whole disks

The disk claiming bit was restricting usage of devices so that it only
worked for whole disks. Now, if we get a partition, then we first
identify the disk the partition is on and then try to claim that disk.

https://bugzilla.novell.com/show_bug.cgi?id=875843