Bug 1123292 - Rubygem-staypuft: HA: pacemaker cluster property are static and not reflect real status of the services.
Summary: Rubygem-staypuft: HA: pacemaker cluster property are static and not reflect r...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-foreman-installer
Version: 5.0 (RHEL 7)
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: Installer
Assignee: Jason Guiditta
QA Contact: Leonid Natapov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-25 09:01 UTC by Leonid Natapov
Modified: 2016-04-27 01:14 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-04 15:00:35 UTC


Attachments (Terms of Use)

Description Leonid Natapov 2014-07-25 09:01:28 UTC
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.

Comment 1 Mike Burns 2014-07-25 09:15:12 UTC
I'm not sure if this is something that ofi sets up or if it should be pacemaker itself.

Comment 3 Fabio Massimo Di Nitto 2014-07-25 13:23:06 UTC
(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.

Comment 4 David Vossel 2014-07-28 14:28:14 UTC
(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

Comment 5 Jason Guiditta 2014-07-28 14:39:36 UTC
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.

Comment 6 Fabio Massimo Di Nitto 2014-07-28 19:26:28 UTC
(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

Comment 7 Jason Guiditta 2014-07-31 20:53:15 UTC
How about 'setup' or 'configured' instead of 'running'?

Comment 8 Fabio Massimo Di Nitto 2014-08-01 05:42:35 UTC
(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..

Comment 11 Mike Orazi 2014-10-01 16:19:57 UTC
Not a blocker, moving for consideration in an unnamed future release.

Comment 12 Jason Guiditta 2016-04-04 15:00:35 UTC
This was never changed, and we are no longer implementing new features for ofi.


Note You need to log in before you can comment on or make changes to this bug.