Red Hat Bugzilla – Bug 1299294
keystone errors in Overcloud deployment with IPv6 enabled
Last modified: 2017-10-30 07:27:55 EDT
Description of problem: When IPv6 is enabled on the latest poodle, the deployment is failing with an error that mentions Keystone. I'm not sure where the error is coming from. Version-Release number of selected component (if applicable): openstack-tripleo-heat-templates.noarch 0.8.6-103.el7ost How reproducible: 100% Steps to Reproduce: 1. Deploy with IPv6 enabled 2. 3. Actual results: Error: Could not prefetch keystone_tenant provider 'openstack': undefined method `collect' for nil:NilClass\u001b[0m\n\u001b[1;31mError: Could not prefetch keystone_role provider 'openstack': undefined method `collect' for nil:NilClass\u001b[0m\n\u001b[1;31m Error: Could not prefetch keystone_user provider 'openstack': undefined method `collect' for nil:NilClass\u001b[0m\n\u001b[1;31mError: /Stage[main]/Keystone::Roles::Admin/Keystone_user_role[admin@admin]: Could not evaluate: undefined method `empty?' for nil:NilClass\u001b[0m\n\u001b[1;31 Expected results: This shouldn't happen. Additional info:
This is usually due to the kesytone service has not started properly. The issue here is that it tries to grab the domain and as the response is coming back empty it triggers this exception.
I seems to me OPM is in a wrong state. Effectively Keystone module is quite old (openstack-puppet-modules-2015.1.8-41.el7ost.noarch latest puddle + poodle (OSP 7): commit 920421a70d33e751c4ec1a665e74819d1c1354d0 Date: Tue Jun 30 14:37:26 2015 +0000 All other modules seems way behind as well. As a matter of fact, testing with latest keystone module from stable/liberty branch doesn't work because many dependent modules are behind too.
Oki, the problem is in that puppet is using the admin_bind_host in /etc/keystone/keystone.conf value to find the keystone server. This variable is set to the local ip, not the vip. Then when puppet try to get to the keystone, it works only on the one where the keystone server is started. Pacemaker policy for keystone is a clone resource, so only one keystone is started.
The problem is actually unrelated to keystone. The issue here is that rabbimq is failing to start on 2 out of 3 nodes. As there is a pacemaker constraint, saying the keystone start after rabbitmq, the keystone service was not started on 2 nodes. The rabbimq tht seems to be missing some IPv6 information to start correctly.
Please ignore my comment#5, OSP 7 is Kilo. My confusion came from the fact it's pointing to a commit (the one corresponding to kilo) on liberty branch.
I wasn't able to reproduce this with openstack-tripleo-heat-templates-0.8.6-120.el7ost.noarch.
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. https://rhn.redhat.com/errata/RHBA-2016-0264.html