Add wait until cluster is stable prior to post-cluster-install tasks

[akrzos]

No description provided.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[akrzos]

/test deploy-5nodes

[akrzos]

/test deploy-5nodes

[josecastillolema]

Test failed because the timeout was too short, I suggest adjusting according to the timeouts that we have in Prow.

[akrzos]

Test failed because the timeout was too short, I suggest adjusting according to the timeouts that we have in Prow.

Got it, I'll try those defaults here with the goal of seeing how long it normally takes a cluster to become stable, I don't really like the idea of adding up to 20m to the length of the playbook so I might default the action to false

[akrzos]

/test deploy-5nodes

[josecastillolema]

Test failed because the timeout was too short, I suggest adjusting according to the timeouts that we have in Prow.

Got it, I'll try those defaults here with the goal of seeing how long it normally takes a cluster to become stable, I don't really like the idea of adding up to 20m to the length of the playbook so I might default the action to false

Having a 20 minutes timeout doesn't mean it's going to add 20 minutes always to the total time, if the cluster is healthy before for 2 minutes then it won't take the full timeout time.

[akrzos]

Test failed because the timeout was too short, I suggest adjusting according to the timeouts that we have in Prow.

Got it, I'll try those defaults here with the goal of seeing how long it normally takes a cluster to become stable, I don't really like the idea of adding up to 20m to the length of the playbook so I might default the action to false

Having a 20 minutes timeout doesn't mean it's going to add 20 minutes always to the total time, if the cluster is healthy before for 2 minutes then it won't take the full timeout time.

Understood, but in theory, it could add up to 20m to tell you that there is a non-stable cluster as well. Some folks don't bother to play with something until they see the current playbook etc run to completion. Also could make CI jobs run 20m to tell you about an unstable cluster. Having ran many tests from jetlag MNO clusters before I actually wasn't even aware all the time that there was still some amount of cluster operator work occurring post assisted installer saying the cluster completed installing.

[akrzos]

Most recent run added 7m and 40s to an MNO deployment, but should ensure that the cluster is stable for day2 operations post deployment:

mno-post-cluster-install : Wait until cluster is stable --------------- 460.44s

[akrzos]

/test deploy-sno

[akrzos]

/test deploy-5nodes

[akrzos]

On my own SNO I observed 5m and 30s to wait for the cluster to become stable.

sno-post-cluster-install : Wait until cluster is stable ------------------------------------------ 330.39s

[josecastillolema]

/lgtm

[akrzos]

/test deploy-sno

[akrzos]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: akrzos

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:

• OWNERS [akrzos]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment