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 #62 from vuntz/db-ha

Get ready for HA in database and rabbitmq
Cleanup neutron-server restart hack

We now delay all the neutron client command until the very end of the
chef-client run. This way we make sure the delayed neutron server restart
actions (triggered by template updates) are processed before the neutron client
commands run. This solution seems to be slightly less hackish.
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
neutron proposal, so only one node should have the password).
Merge pull request #64 from rhafer/postinstall-cleanup

Cleanup neutron-server restart hack
Use new synchronization helpers to avoid races when deploying with HA

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

 - when creating of the database / database user
 - when registering the endpoint and creating users in keystone
Manage neutron-server with pacemaker

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

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

Use new synchronization helpers + manage services with pacemaker
Rename [:ha][:enabled] attribute to [:ha][:server][:enabled]

This will allow us to introduce :ha][:l3][:enabled] later to differentiate
between the HA setups of neutron-server and l3-agent.
Skeleton code for l3-agent ha

This introduces the HA enablement pieces for the l3-agent. Currently this l3_ha
recipe is still a dummy and does nothing useful.
Implement l3_ha recipe

Create pacemaker primitive, group and clone for the various neutron agents.
Setup the neutron-ha-tool to perform automatic migrations of offline
routers.
l3_ha: Don't start l3-agent when using "vmware" networking
Include linux-bridge/ovs-agent into the l3 HA group
Add an order constraint for neutron-ha-tool

This should make sure that the neutron-agents clone is started before the
neutron-ha-tool primitive. Otherwise neutron-ha-tool might cause unneeded
router migrations.
Use pacemaker service provider when HA is enabled
Derive the resource agent name attributes from the service names
Only install ha-tool package on platforms that have it
Use synchronization helpers in l3_ha to avoid races when deploying with HA