Reduce total duration of clusterctl tests by switching from wait.Poll to wait.PollImmediate(...)

[spew]

What this PR does / why we need it:
This PR improves the runtime of the clusterctl unit tests by polling immediately for changes instead of waiting first. On my Mac the runtime is reduced from ~48 seconds to around 10 seconds. A runtime comparison of the clusterctl folder's for go test ./...

BEFORE:

$ go test ./...
?   	sigs.k8s.io/cluster-api/clusterctl	[no test files]
ok  	sigs.k8s.io/cluster-api/clusterctl/clusterdeployer	47.809s
ok  	sigs.k8s.io/cluster-api/clusterctl/clusterdeployer/minikube	0.038s
ok  	sigs.k8s.io/cluster-api/clusterctl/cmd	0.180s

AFTER

$ go test ./...
?   	sigs.k8s.io/cluster-api/clusterctl	[no test files]
ok  	sigs.k8s.io/cluster-api/clusterctl/clusterdeployer	9.885s
ok  	sigs.k8s.io/cluster-api/clusterctl/clusterdeployer/minikube	0.025s
ok  	sigs.k8s.io/cluster-api/clusterctl/cmd	0.192s

Release note:

Small improvement in the duration of clusterctl create cluster by polling for changes immediately. 

@kubernetes/kube-deploy-reviewers

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: spew

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 [spew]

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

[spew]

/assign @jessicaochen @karan

[dims]

/lgtm

[k8s-ci-robot]

@dims: changing LGTM is restricted to assignees, and only kubernetes-sigs/cluster-api repo collaborators may be assigned issues.

In response to this:

/lgtm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[karan]

/hold

[karan]

Question - how does it affect the actual runtime?

The docs see to be not accurate here https://github.com/kubernetes/apimachinery/blob/master/pkg/util/wait/wait.go#L230

[jessicaochen]

I had would have thought Poll would check a condition first before going into the wait. Is there any reason not to have wait.PollImmediate be our default Poll?

[spew]

@karan for the real runtime i think the effect will be negligable because often times the first poll won't be successful anyway (i.e. more time needs to be waited until the condition becomes true).

From the docs for wait.Poll:

// Poll always waits the interval before the run of 'condition'.
// 'condition' will always be invoked at least once.

From the docs for wait.PollImmediate

// Poll always checks 'condition' before waiting for the interval. 'condition'
// will always be invoked at least once.

I am not seeing any inaccuracy. However, there does seem to be a mistake in that the "Immediate" is missing after Poll so maybe that's where the confusion comes from.

[spew]

@jessicaochen Most likely our default Poll should be PollImmediate, however, I limited the scope of this change to only the code I was testing directly.

[spew]

Opened a PR for fixing the wait.PollImmediate docs here: kubernetes/kubernetes#65026

[jessicaochen]

Sure, could you create an issue to track making PollImmediate our repo default so we have consistency in the future?

[spew]

Created an issue for that: #336

[jessicaochen]

lgtm (leaving backslash for seconary lgtm-er)

[spew]

@karan could please take another look.

[karan]

/lgtm

[spew]

/hold cancel