Moved role constraints into model and removed edit deployment
Merge pull request #62 from tboerger/feature/constraint-move

Moved role constraints into model and removed edit deployment
Merge pull request #63 from crowbar/release/stoney/master

Sync with stoney (only change is role constraints)
Removed the single assignment block from constraints
Merge pull request #64 from tboerger/feature/roxy/fix-constraints

Removed the single assignment block from constraints
Add a helper to get the listen address of the database

This will be used by other cookbooks from other barclamps to get the IP
address of the database, and this can then be changed when we add HA.
Merge pull request #66 from vuntz/helper-before-ha

Add a helper to get the listen address of the database
Create postgresql password in barclamp, not in cookbook

This way, it can be shared among multiple nodes.
Remove setting api_bind_host attribute in barclamp

This is unused.
Do not change db_maker user at every chef run

We were not using the right password to test if we could connect!
Initial support for HA by assuming shared storage

We do not handle in any way the shared storage here; it could be
something to look at.
Add ability to use shared storage
Use new synchronization helpers to avoid races when deploying with HA

This helps avoid races when creating the pacemaker resources, either
because database is not installed on one node yet (resulting in the
pacemaker resource not being runnable on that node) or because the
pacemaker resources are created at the same time on multiple nodes.
Use new Chef::Provider::CrowbarPacemakerService provider
Include the HA recipe earlier

As we generate a config file based on a template in the directory that
will be the target for a mount when using HA, we need to get this mount
handled early.
ha: Only run the psql commands if postgresql is running on this node

Otherwise, we're subject to races where we reach that code before the
node hosting postgresql is fully configured to answer to psql.
Wait for the shared storage/drbd mount to be started somewhere

If we're too fast, we could generate some files in the directory that
will be mounted to, before the device is mounted, resulting in the
database to use the wrong config files.
Split the HA code in two recipes for more reliability

Because postgresql has config files not in /etc but in
/var/lib/pgsql/data (which is inside the mount that we use for
postgresql storage when in HA mode), the setup is quite tricky to get
right.

We must first setup the storage bits of the HA, so that we can write the
configuration files in the right place.

Once we have the configuration files inside the mount, then we can
configure (and therefore start) the postgresql pacemaker resource.
Otherwise, we're having a race, with postgresql starting before the
mount is completed on this node.

In addition to that, we used to rely on postgresql starting to generate
some of the files (thanks to initdb). We now have to do that manually.

In the non HA mode, we didn't have that many issues with the order,
because we do not use a mount which might not be there when creating the
configuration files.
Switch to the OCF RA for postgresql
Wait for postgresql to answer before going on