Make wait_for_endpoints more robust. #1172
Conversation
As seen in Bug #2045206 wait_for_endpoints can fails if keystone is in a transient state. This change puts tenacity around the keystone client setup to make it more resilient. Closes-Bug: 2045206
| @@ -192,17 +192,34 @@ def wait_for_url(url, ok_codes=None): | |||
| assert r.status_code in ok_codes | |||
|
|
|||
|
|
|||
| def wait_for_client(): | |||
There was a problem hiding this comment.
nitpick: the function's name is a bit strange ... it's waiting, but also returning a value ... the "waiting" seems to be irrelevant from the caller's perspective, why not call it "get_keystone_client"?, or maybe re-use get_keystone_client()[0] and wrap that one with a retry() decorator?, if there is a concern about the retry on a core function like this one, the number of retries could be an argument that defaults to 1
There was a problem hiding this comment.
I agree that the function's name is wrong. I don't think that get_keystone_client() can be used as it seems more basic that this function; i.e. it's using overcloud auth rather than openrc.
I think this function ought to be in z.o.utilities.openstack.py though along with the other keystone client functions which would also open a space for refactoring at a future point.
Finally, the wait_for_url() function is also really generic and probably could also live in a utility module; the wait_for_all_endpoints() a bit more arguable as to where it should go. It's specific enother to be testing keystone ... but also generic enough that other tests might also want to wait on the endpoints being available as a utility.
There was a problem hiding this comment.
LGTM. Thanks for making the changes. I will give @ajkavanagh the chance to chime in before merging.
As seen in Bug #2045206 wait_for_endpoints can fails if keystone is in a transient state. This change puts tenacity around the keystone client setup to make it more resilient.
Closes-Bug: 2045206