Fix conversion of per node stonith parameters

This converts the per node stonith parameters from Chef::Node::Attribute to a
"normal" ruby hash when stripping the domain from the node names. It seems
assigning a hash of Chef::Node::Attribute objects to the node attributes
doesn't work. When accessing the values later on (in pacemaker::stonith) they
just evaluated to nil.

https://bugzilla.novell.com/show_bug.cgi?id=887244
Fix extraction of stonith parameter from parameter string

Pacemaker::Resource.extract_hash() is written to extract things from a complete
CIB object definition. Therefore it rightfully expects whitespaces before the
data_type ("params" in this case). So we just add those here to make the string
parsable by extract_hash.

https://bugzilla.novell.com/show_bug.cgi?id=887244
Merge pull request #121 from rhafer/per_node_stonith

Per node stonith config
Fix javascript after barclamp-crowbar change

https://github.com/crowbar/barclamp-crowbar/pull/1091 exposes a bug in
the javascript where we don't specify the default value of a json
attribute we try to read and that doesn't initially exist.
Merge pull request #122 from vuntz/fix-js

Fix javascript after barclamp-crowbar change
Properly escape the per-node STONITH parameters

https://bugzilla.novell.com/show_bug.cgi?id=888637
Merge pull request #124 from vuntz/escape-per-node

Properly escape the per-node STONITH parameters
Fix validation of SBD devices when none is specified

https://bugzilla.novell.com/show_bug.cgi?id=888060
webui: Do not save empty sbd device if there's a trailing , or space
Merge pull request #123 from vuntz/fix-validation-sbd

Fix validation of SBD devices when none is specified
use --wait with crm node maintenance/ready to avoid races

https://mailman.suse.de/mailman/private/ha-devel/2014-May/003603.html
(sorry - SUSE internal-only mailing list; but thread available on request)
use --wait with crm resource start/stop to avoid races

https://mailman.suse.de/mailman/private/ha-devel/2014-May/003603.html
(sorry - SUSE internal-only mailing list; but thread available on request)
Start STONITH primitive resources

For some reason, sometimes, I see them not running after the cluster
creation. Since we're supposed to explicitly start all primitives, this
should work better.
adding recipe for creating apache pacemaker primitive
(to be reusable from other barclamps)

include apache2::mod_status

pick non-ssl port for server-status

porvide list of ports for a service; correct way to find existing one
Merge pull request #129 from jsuchome/add_apache_recipe

adding recipe for creating apache pacemaker primitive
Merge pull request #131 from vuntz/start-stonith

Start STONITH primitive resources
Always remove deprecated target-role meta on update of a primitive

We deprecated setting target-role values via the meta attribute, in
favor of :start/:stop actions on the resource. So this should not be
relied upon anymore, and it's safe to drop this if we want to.

There is one racy case where this matters:
  - node1 and node2 try to create a primitive with the chef resource; on
    initial creation, we set target-role='Stopped' because we do not
    want to autostart primitives.
  - because they can't create it at the same time, node2 will fail on
    creation. If the chef resource is configured to retry, then node2
    will then try to update the primitive (since it now exists); but the
    chef resource is not reloaded so still has target-role='Stopped'.
  - if node1 had also started the primitive before node2 retries the
    :create, then the target-role will be changed from 'Started' to
    'Stopped' with the update.

This can result in a primitive not being started with [:create, :start].
Therefore, we just delete this deprecated bit from meta to avoid any issue.

[Thu, 31 Jul 2014 15:11:55 +0200] INFO: Processing pacemaker_primitive[vip-public-cluster-proposal-1] action create (crowbar-pacemaker::haproxy line 15)
[Thu, 31 Jul 2014 15:11:56 +0200] INFO: Creating new primitive resource 'vip-public-cluster-proposal-1'
[Thu, 31 Jul 2014 15:11:56 +0200] INFO: Processing execute[crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped" ] action run (/var/chef/cache/cookbooks/pacemaker/libraries/chef/mixin/pacemaker/sta
ndard_cib_object.rb line 91)

================================================================================
Error executing action `run` on resource 'execute[crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped" ]'
================================================================================

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped"  ----
STDOUT:
STDERR: ERROR: vip-public-cluster-proposal-1: id is already in use
---- End output of crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped"  ----
Ran crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped"  returned 1

[...]

[Thu, 31 Jul 2014 15:11:56 +0200] INFO: Retrying execution of pacemaker_primitive[vip-public-cluster-proposal-1], 0 attempt(s) left
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: Checking existing primitive resource 'vip-public-cluster-proposal-1' for modifications
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: vip-public-cluster-proposal-1's ip params didn't change
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: vip-public-cluster-proposal-1's target-role meta changed from  to Stopped
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: Processing execute[crm_resource --resource vip-public-cluster-proposal-1 --set-parameter "target-role" --parameter-value "Stopped" --meta] action run (/var/chef/cache/cookbooks/pacemaker/providers/primitive.rb line 88)
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: execute[crm_resource --resource vip-public-cluster-proposal-1 --set-parameter "target-role" --parameter-value "Stopped" --meta] ran successfully
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: Processing execute[crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped" ] action nothing (/var/chef/cache/cookbooks/pacemaker/libraries/chef/mixin/pacemaker
/standard_cib_object.rb line 91)
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: Processing execute[crm_resource --resource vip-public-cluster-proposal-1 --set-parameter "target-role" --parameter-value "Stopped" --meta] action nothing (/var/chef/cache/cookbooks/pacemaker/providers/primitive.rb line 88)
Merge pull request #130 from vuntz/no-Stopped-on-retry

Do not force target-role to Stopped on retry of creation of a primitive
Merge pull request #128 from aspiers/crm-wait-sync-master

use crm --wait to avoid races (stoney)
Sort vip primitives when creating haproxy group

Without the sort, the order of the VIP can change, and we keep updating
the haproxy group every now and then.