Description of problem: Rubygem-staypuft: HA: pacemaker cluster property are static and not reflect real status of the services. I've deployed HA + Nova Compute. for example I've stopped heat and keystone services. [root@maca25400868093 ~]# openstack-service status keystone openstack-keystone (pid 0) is inactive also pcs status shows: openstack-keystone_monitor_30000 on maca25400868093.example.com 'not running' but pacemaker cluster property shows Cluster Properties: cinder: running cluster-infrastructure: corosync dc-version: 1.1.10-32.el7_0-368c726 galera: running glance: running heat: running horizon: running keystone: running Het is also stopped but it shows as running. So it seems that pacemaker cluster property are static and not reflect real status of the services.
I'm not sure if this is something that ofi sets up or if it should be pacemaker itself.
(In reply to Mike Burns from comment #1) > I'm not sure if this is something that ofi sets up or if it should be > pacemaker itself. This is something ofi sets. pacemaker doesn't set cluster properties after service names. The point here is: - pacemaker has no use for those properties - those properties are used by ofi only - they do not reflect the current status (if anything ofi has to update them) - they can be confusing for GSS/users. Best path forward is to understand why they are there and what's their purpose, then eventually handle them as necessary.
(In reply to Fabio Massimo Di Nitto from comment #3) > (In reply to Mike Burns from comment #1) > > I'm not sure if this is something that ofi sets up or if it should be > > pacemaker itself. > > This is something ofi sets. pacemaker doesn't set cluster properties after > service names. > > The point here is: > > - pacemaker has no use for those properties > - those properties are used by ofi only > - they do not reflect the current status (if anything ofi has to update them) > - they can be confusing for GSS/users. Right. these properties mean nothing to pacemaker. They've been created and set outside of pacemaker. Pacemaker is just storing those values for us. > Best path forward is to understand why they are there and what's their > purpose, then eventually handle them as necessary. If you all need any help understanding how to reliably parse resource status information, please let me know. I'd be happy to review anything involving Pacemaker integration. -- Vossel
These properties are entirely for ofi/quickstack, for determining cross-machine puppet orchestration. This is not affected by later stops to the service, but is needed to make sure puppet does not do something it shouldn't on a later run. This is not a bug.
(In reply to Jason Guiditta from comment #5) > These properties are entirely for ofi/quickstack, for determining > cross-machine puppet orchestration. This is not affected by later stops to > the service, but is needed to make sure puppet does not do something it > shouldn't on a later run. This is not a bug. but the wording is misleading. "service: running" provides a status of a service that indeed might be failed. this is confusing at best for users and customer supports. Use all the keywords you need, but use words that will not generate confusion
How about 'setup' or 'configured' instead of 'running'?
(In reply to Jason Guiditta from comment #7) > How about 'setup' or 'configured' instead of 'running'? Sure, or use a prefix: service_foo: puppet_configured, puppet_setup..
Not a blocker, moving for consideration in an unnamed future release.
This was never changed, and we are no longer implementing new features for ofi.