Use attribute from rabbitmq node to get rabbitmq IP address

The rabbitmq cookbook saves the IP address used by rabbitmq to listen,
so no need to do some fancy thing to get it.
Use helper from database cookbook to get database IP address

This way we're ready for when HA will be used for database.
Merge pull request #159 from vuntz/db-ha

Get ready for HA in database and rabbitmq
Update db password migration script to remove node attributes

On update, we want to use the db password from the proposal / role, and
not the one that might have been generated on the node (through the
cookbook). As the password is a "normal" attribute on the node, but a
"default" attribute on the role, the old one from the node is used.
Which means we really need to remove it to get the new one used.

To minimize config changes, we actually import the password from one
node (which should be good enough in most cases as we allow only one
cinder proposal, so only one node should have the password).
Use new synchronization helpers to avoid races when deploying with HA

There are a number of possible races when deploying cinder for the
first time:

 - when creating of the database / database user
 - when registering the endpoint and creating users in keystone
Manage cinder-api and cinder-scheduler with pacemaker

We create the primitives/group/clone resources (protected with
crowbar_pacemaker_sync_mark) and we use the
Chef::Provider::CrowbarPacemakerService service provider.
Merge pull request #160 from vuntz/drop-db-node

Update db password migration script to remove node attributes
Merge pull request #161 from vuntz/sync-marks

Use new synchronization helpers + manage services with pacemaker
Add insecure flag to keystone_authtoken config when required
Merge pull request #163 from rhafer/keystone_insecure

Add insecure flag to keystone_authtoken config when required
ha: Follow convention for pacemaker resource naming
ha: Do not pass is-managed / target-role meta when creating resources

We are happy with the default values.
Merge pull request #165 from vuntz/ha-convention

Update pacemaker resource names + other conventions for HA
Run "cinder-manage db sync" on SUSE when HA is enabled

So far, we were not running it because the init script on SUSE does run
it. But with HA enabled, the service starts at the same time on all
nodes, which may result in failures on some nodes because db sync can't
be run multiple times simultaneously. The end result is that the
pacemaker resource was possilby failing on some nodes, which then
required some manual cleanup.
Update for prepare_role_for_ha_with_haproxy API change
Merge branch 'release/roxy/master' into roxy-sync
Merge pull request #168 from vuntz/roxy-sync

Merge roxy branch into stoney
Merge pull request #167 from vuntz/api-change

Update for prepare_role_for_ha_with_haproxy API change
Only run the db_sync the very first time (on SUSE, at least)
Do the db sync only on initial run, and on all platforms