Running "make test" fails in random ways in TestValidatePorts on WSL

[rmsilva1973]

What Happened?

Running "make test" on WSL fails with random ports on TestValidatePorts. Here are two samples:

--- FAIL: TestValidatePorts (0.00s)
--- FAIL: TestValidatePorts/0-1:80-81/udp (0.00s)
start_test.go:742: validatePorts(ports=[0-1:80-81/udp]): got Sorry, you cannot use privileged ports on the host (below 1024): 1, expected Sorry, one of the ports provided with --ports flag is outside range: 0

--- FAIL: TestValidatePorts (0.00s)
--- FAIL: TestValidatePorts/127.0.0.1:80-83:80-83/udp (0.00s)
start_test.go:742: validatePorts(ports=[127.0.0.1:80-83:80-83/udp]): got Sorry, you cannot use privileged ports on the host (below 1024): 83, expected Sorry, you cannot use privileged ports on the host (below 1024): 80

Tracking down the reason for this, I think it's due to the assumption that this loop on a map object returns the elements in an ordered way:

minikube/cmd/minikube/cmd/start.go

Lines 1359 to 1364 in 1b0d879

	for exposedPort, portBindings := range portBindingsMap {
	exposedPorts = append(exposedPorts, exposedPort.Port())
	for _, portBinding := range portBindings {
	hostPorts = append(hostPorts, portBinding.HostPort)
	}
	}

But apparently this doesn't seem to be true. Thus the test for ports "127.0.0.1:80-83:80-83/udp" like the example above returns an error validating a port different than 80 initially (83 in the specific run depicted above).

If my statement is correct, I have a proposal: add a "hasRegex" field to the structs inside the portTest array whose definition begins here:

minikube/cmd/minikube/cmd/start_test.go

Line 579 in 1b0d879

var tests = []portTest{

like this:

var tests = []portTest{
    {
        isTarget: isMicrosoftWSL,
	ports:    []string{"127.0.0.1:80-83:80-83/tcp"},
        hasRegex: true,               
	errorMsg: "Sorry, you cannot use privileged ports on the host (below 1024): 8[0-3]",
    },

and then apply and validate the errorMsg using the regex when required. It seems better than assuming every errorMsg has regex since we'll be splattering escape characters all over them.

Another idea would be to search the first port and validate only that one. But this seems to be a rather lame way to handle it.

Attach the log file

Validation error samples:

--- FAIL: TestValidatePorts (0.00s)
--- FAIL: TestValidatePorts/0-1:80-81/udp (0.00s)
start_test.go:742: validatePorts(ports=[0-1:80-81/udp]): got Sorry, you cannot use privileged ports on the host (below 1024): 1, expected Sorry, one of the ports provided with --ports flag is outside range: 0

--- FAIL: TestValidatePorts (0.00s)
--- FAIL: TestValidatePorts/127.0.0.1:80-83:80-83/udp (0.00s)
start_test.go:742: validatePorts(ports=[127.0.0.1:80-83:80-83/udp]): got Sorry, you cannot use privileged ports on the host (below 1024): 83, expected Sorry, you cannot use privileged ports on the host (below 1024): 80

Operating System

Ubuntu

Driver

N/A

[rmsilva1973]

/assign rmsilva1973

[rmsilva1973]

Will create a PR. Will wait a little bit for the opinions on the proposed alternatives (or any other additional considerations).

[rmsilva1973]

/kind failing-test

[rmsilva1973]

@spowelljr any considerations on this? 😁

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.