OCF resource agent out of date or HA guide incorrect.

Bug #1735192 reported by netproducts
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openstack-manuals
Invalid
Undecided
Unassigned
openstack-resource-agents
Confirmed
Undecided
Adam Spiers

Bug Description

The HA guide over at

https://docs.openstack.org/ha-guide/controller-ha-identity.html

recommends downloading an OCF resource agent from git. This OCF resource agent is now about 18 months old, dating from early 2016. It still uses the commands 'keystone-all' and 'keystone'. Both executables no longer exist, so the resource agent does not work as-is.

The newer commands are 'keystone-manage' and 'openstack'

In addition, 'keystone user-list' is wrong syntax, it should now be 'openstack user list'
Here's a diff of the changes I made;

<code>

38c38
< OCF_RESKEY_binary_default="keystone-manage"
---
> OCF_RESKEY_binary_default="keystone-all"
42c42
< OCF_RESKEY_client_binary_default="openstack"
---
> OCF_RESKEY_client_binary_default="keystone"
250c250
< user list > /dev/null 2>&1
---
> user-list > /dev/null 2>&1

</code>

While this fixes errors in the resource agent, It's still impossible for me to run keystone via the OCF, simply because, since those commands were removed, there's no way for me to stop keystone from running directly.

In addition, I can't help but notice the HA guide only speaks about RHEL and SUSE. Where's the Ubuntu section for Keystone HA? It's there for the other components...

ps aux | grep keystone

returns 10 lines like these;

keystone 10173 0.0 1.8 409096 111612 ? Sl 06:25 0:17 (wsgi:keystone-pu -k start

This means keystone runs under the apache2 web server.
Thus if we add the apache2 systemd script ('systemctl start apache2') to the pacemaker cluster as a cloned service, then it should be able to manage keystone.

Why would you want this, instead of just running systemd on separate hosts? Well, other services kind of 'depend' on keystone, as such you can create hooks in crmsh to ensure that the active/passive services, which actually require crmsh, only start after keystone is available.

E.g. this code suffices to switch keystone from the default 'systemd' managed setup to a crm-managed setup on ubuntu or debian with N nodes;
<code>
node1> systemctl stop apache2
node1> systemctl disable apache2
node2> systemctl stop apache2
node2> systemctl disable apache2
....
nodeN> systemctl stop apache2
nodeN> systemctl disable apache2
node1> crm
crm$ configure primitive p_keystone systemd:apache2 op monitor interval="30s" timeout="30s"
crm$ configure clone keystone_clone p_keystone
</code>

description: updated
Revision history for this message
Lance Bragstad (lbragstad) wrote :

This looks like a bug in the HA guide, which should be in the openstack-manuals project. Adding openstack-manuals to this report for further clarification.

no longer affects: keystone
Revision history for this message
Ian Y. Choi (ianychoi) wrote :

Since the file locates in https://git.openstack.org/cgit/openstack/openstack-resource-agents/ , the file needs to be fixed IMO.

Changed in openstack-manuals:
status: New → Opinion
Revision history for this message
Adam Spiers (adam.spiers) wrote :

Yes this is correct, I have done a bad job of maintenance here. I should have some time to address it at the PTG next week.

Changed in openstack-manuals:
status: Opinion → Confirmed
Changed in openstack-resource-agents:
status: New → Confirmed
assignee: nobody → Adam Spiers (adam.spiers)
Revision history for this message
Frank Kloeker (f-kloeker) wrote :

seems not related to openstack-manuals

Changed in openstack-manuals:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.