Race condition between haproxy and keystone register task
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
kolla-ansible |
Fix Released
|
Medium
|
Juan J. Martínez |
Bug Description
When keystone register tasks run, it is possible that "Creating default user role" runs before haproxy detects keystone services are up.
When that happens, "Creating default user role" fails:
TASK [keystone : Creating default user role] *******
task path: /usr/share/
Using module file /usr/share/
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0'
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /root/.
<localhost> PUT /tmp/tmpNbygO4 TO /root/.
<localhost> EXEC /bin/sh -c 'chmod u+x /root/.
<localhost> EXEC /bin/sh -c '/usr/bin/python /root/.
fatal: [localhost]: FAILED! => {
"changed": false,
"failed": true,
"invocation": {
},
}
},
}
},
"msg": "Could not determine a suitable URL for the plugin"
}
This issue appeared after this change: https:/
Previous task ("Creating admin project, user, role, service, and endpoint") works fine because it performs a keystone-manage bootstrap, and that uses SQL directly instead of the API.
Suggested solutions include:
* revert part of the mentioned change, so the task retries
* wait for the port to be ready
description: | updated |
Changed in kolla-ansible: | |
assignee: | nobody → Juan J. Martínez (jjmartinez) |
status: | New → In Progress |
Changed in kolla-ansible: | |
importance: | Undecided → Medium |
milestone: | none → pike-3 |
On second thought, waiting for the port is not good enough as haproxy is always bound; unless we check for a specific HTTP response.
Retry should be fine though.