Rubygem-staypuft: HA: Relax the openstack-heat-engine: op monitor interval to 60 seconds.
Now it's openstack-heat-engine: op monitor interval=30s
appears to be too resource consuming in some cases (like openstack-heat-engine and causes false positives.
This bug causes heat service to go up/down at random interval. I consider this a blocker.
Patch posted: https://github.com/redhat-openstack/astapor/pull/338
It looks like the heat how-to should be updated as well.
(In reply to Crag Wolfe from comment #3)
> It looks like the heat how-to should be updated as well.
I don't understand the point here.
The heat how-to uses the default monitor op of 60 seconds by not specifying any value.
pcs resource create heat-engine systemd:openstack-heat-engine op monitor start-delay=10s
default is 60.
My mistake, I did not realize the 60s was global across all services. Should we open another bug to change the interval to 60s for all services (right now the default is 30s as deployed by puppet)?
(In reply to Crag Wolfe from comment #6)
> My mistake, I did not realize the 60s was global across all services.
> Should we open another bug to change the interval to 60s for all services
> (right now the default is 30s as deployed by puppet)?
It's a bit tricky here. I think default should be 60 and match pacemaker default but we probably want the ability to configure that value.
Now, I experienced those timeout because hw was "questionable" and slow. Customers might not experience the same and perhaps want faster failure detection.
[root@mac047d7b627d5a haproxy]# pcs resource show openstack-heat-engine
Resource: openstack-heat-engine (class=systemd type=openstack-heat-engine)
Operations: monitor interval=60s (openstack-heat-engine-monitor-interval-60s)
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.