feat: have pre-req retry upon check fail #574
Conversation
Signed-off-by: Humair Khan <HumairAK@users.noreply.github.com>
|
A new image has been built to help with testing out this PR: To use this image run the following: cd $(mktemp -d)
git clone git@github.com:opendatahub-io/data-science-pipelines-operator.git
cd data-science-pipelines-operator/
git fetch origin pull/574/head
git checkout -b pullrequest fd3aae9110a4857e71e81f8ab9774e13186d389f
oc new-project opendatahub
make deploy IMG="quay.io/opendatahub/data-science-pipelines-operator:pr-574"More instructions here on how to deploy and test a Data Science Pipelines Application. |
There was a problem hiding this comment.
I didn't face the issue mentioned in Jira as the Database was available within 1 second after the failure of the Database Health Check as you can see in the screenshot.
My question is only regarding the aggressive 'RequeAfter' duration of 20 seconds. Is it more of a end-user experience kind of thing to go ahead with provisioning the rest of the pods with DSPA once the Database Health Check passes by reconciling aggressively? Any performance hiccups with such a short duration for reconciliation would be my only question. This can be taken offline but the code looks perfect and Works perfectly fine with sanity checks.
|
/lgtm it's a little more common to do exponential backoff in controllers. Can be a future improvement (or not). |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: amadhusu, gregsheremeta The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The issue resolved by this Pull Request:
Resolves https://issues.redhat.com/browse/RHOAIENG-2099
Same as: #571 for v1.6