So, looking at the how to, heat engine is set to active-passive unless ceilometer is configured, which it is not, yet, so I am not sure this will work as intended with our existing codebase.  I think with A/P for heat-engine, this would effectively make api-cloudwatch also A/P, even though we have it A/A right now.  From the howto[1]

# heat-engine can do A/A but requires OS::Ceilometer::Alarm in templates
# that means:
# 1) ceilometer must be working before heat
# 2) if somebody overrides a template can it go kaboom?
# 3) let´s start basic with A/P, we can easily tune it later on.

pcs resource create heat-engine systemd:openstack-heat-engine op monitor start-delay=10s

The constraints are then listed as:

pcs constraint order start heat-api-cloudwatch-clone then heat-engine-clone
pcs constraint colocation add heat-engine with heat-api-cloudwatch

Clearly the second is what you are asking for, but notice the first, which refers to heat-engine-clone, which is not what we created in the step before.  If Fabio and company say it is ok to mix these, I am happy to add it, I am just concerned that the A/A setup and thus the cool constraint are required, in which case we need to have this depend on the HA ceilometer feature, which has not yet been started.

[1] https://github.com/fabbione/rhos-ha-deploy/blob/master/rhos5-rhel7/mrgcloud-setup/RHOS-RHEL-HA-how-to-mrgcloud-rhos5-on-rhel7-heat-latest.txt

(In reply to Jason Guiditta from comment #1)
> So, looking at the how to, heat engine is set to active-passive unless
> ceilometer is configured, which it is not, yet, so I am not sure this will
> work as intended with our existing codebase.  I think with A/P for
> heat-engine, this would effectively make api-cloudwatch also A/P, even
> though we have it A/A right now.  From the howto[1]
> 
> # heat-engine can do A/A but requires OS::Ceilometer::Alarm in templates
> # that means:
> # 1) ceilometer must be working before heat
> # 2) if somebody overrides a template can it go kaboom?
> # 3) let´s start basic with A/P, we can easily tune it later on.
> 
> pcs resource create heat-engine systemd:openstack-heat-engine op monitor
> start-delay=10s
> 
> The constraints are then listed as:
> 
> pcs constraint order start heat-api-cloudwatch-clone then heat-engine-clone
> pcs constraint colocation add heat-engine with heat-api-cloudwatch
> 
> Clearly the second is what you are asking for, but notice the first, which
> refers to heat-engine-clone, which is not what we created in the step
> before.  If Fabio and company say it is ok to mix these, I am happy to add
> it, I am just concerned that the A/A setup and thus the cool constraint are
> required, in which case we need to have this depend on the HA ceilometer
> feature, which has not yet been started.
> 
> [1]
> https://github.com/fabbione/rhos-ha-deploy/blob/master/rhos5-rhel7/mrgcloud-
> setup/RHOS-RHEL-HA-how-to-mrgcloud-rhos5-on-rhel7-heat-latest.txt

oh you are mixing up things too much.

heat-engine is A/P: check.

pcs constraint colocation add heat-engine with heat-api-cloudwatch

does NOT make heat-api-cloudwatch A/P. it means that heat-engine should be running together with *ANY* of the instances of api-cloudwatch. Doesn't matter which one.

using heat-api-cloudwatch or heat-api-cloudwatch-clone is irrelevant for the constraint location.

It makes a slightly small difference in the start order by shaving a second or two.

PR submitted

https://github.com/redhat-openstack/astapor/pull/351

Updated PR https://github.com/redhat-openstack/astapor/pull/353

merged by cwolfe

openstack-foreman-installer-2.0.20-1.el6ost

[root@mac047d7b627d5a haproxy]# pcs constraint | grep heat
  start openstack-heat-api-clone then start openstack-heat-api-cfn-clone
  start openstack-heat-api-cfn-clone then start openstack-heat-api-cloudwatch-clone
  start openstack-heat-api-cloudwatch-clone then start openstack-heat-engine
  openstack-heat-api-cfn-clone with openstack-heat-api-clone
  openstack-heat-api-cloudwatch-clone with openstack-heat-api-cfn-clone
  openstack-heat-engine with openstack-heat-api-cloudwatch-clone

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1090.html