Clarify "crowbar_pacemaker_sync_mark" comments a bit
Merge pull request #84 from rhafer/clarify

Clarify "crowbar_pacemaker_sync_mark" comments a bit
Fix copy'n paste error in default attributes

This resulted in neutron-metadata-agent to running in an HA enabled
setup. (bnc#875178)
Merge pull request #87 from rhafer/ha-metadata-agent

Fix copy'n paste error in default attributes
Fix the schema migration that adds the neutron-l3 role

The nodes that had the "neutron-server" role assigned before also need
"neutron-l3" after upgrading the schema. Otherwise they end up with an
incomplete run_list. (bnc#875022)
Merge pull request #86 from rhafer/fix-l3-migration

Fix the schema migration that adds the neutron-l3 role
ha: Fix initial DB sync

The initial database sync for neutron doesn't occur with
"neutron-db-manage check_migration"; it occurs when the neutron-server
daemon starts. This is perfect for non-HA, but breaks for HA since
cluster members will run this concurrently and will fail to execute the
db migrations all at the same time.

To make this work, I can't think of any other way than starting once
neutron-server (to get the db sync) and then stopping it, to then hand
over all of this to pacemaker. We only do this for HA (since it's
useless without HA) and we only do this the first time on the cluster
founder (like before, for the old code we thought would work).
Minor cleanup

- remove unused variable
- fixed indentation
- Get the floating network's VLAN id from the correct value of the network
  attribute. It doesn't make a real difference as the public and floating VLANs
  need to be the same currently. But this is cleaner.
Merge pull request #88 from vuntz/ha-db-migrate

ha: Fix initial DB sync
Re-arranged generation of provider network options

There should be no difference between provider networks generated for
linuxbridge or openvswitch setups, when using the "VLAN" networking modes.

Previously we didn't add any --provider options in openvswitch based setups.
Which cause the segmentation_id attribute to be auto-populated with a wrong
value.
Honor the :use_vlan flag when creating the floating network

If use_vlan is false for the floating network we need to create the floating
network with type "flat". Otherwise it will endup being tagged to a VLAN and be
inaccessible from the public network (especially when using linuxbridges).
Merge pull request #91 from rhafer/floating_no_vlan

Fix creation of floating network when vlan is disabled.