add kind dual presubmits

[aojea]

Now that dualstack is supported in KIND "officially" , and that those jobs were running for a while without issues we can run them in presubmits.

https://testgrid.k8s.io/sig-network-kind#sig-network-kind,%20dual,%20master&width=20

There are 2 dual-stack presubmit jobs depending on the kube-proxy implementation.
The ipvs one will run only if some ipvs code has changed.
The iptables one will run on every commit, but it will be optional without reporting status to let it soak.

xref: kubernetes-sigs/kind#2172

[aojea]

/assign @thockin @BenTheElder

[aojea]

/retest

[aojea]

is this something am I doing wrong?
pull-test-infra-gubernator — Job failed.

...............WARNING:root:label event with no labels (multiple changes?)
...ERROR:root:webhook failed signature check
.ERROR:root:webhook failed signature check
........................ERROR:root:unable to fetch 'http://testbed.example.com/_ah/gcs/foo/quux': status code 404
....ERROR:root:failed to get user name: status 403
.ERROR:root:failed to vend token: status 403

[aojea]

/retest

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: aojea
To complete the pull request process, please ask for approval from bentheelder after the PR has been reviewed.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• config/jobs/kubernetes/sig-network/OWNERS [aojea]
• config/testgrids/kubernetes/presubmits/OWNERS
• gubernator/OWNERS

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

[aojea]

Ben is out this week
/assign @spiffxp

[spiffxp]

Three always run kind jobs is a lot. Can we replace the other two with this? Or at least one of them? We should definitely not skip reporting unless the intent is to gain confidence to replace

[aojea]

this is to gain confidence ...
we need the ipv6 only because is the only job that gates on ipv6 ...
the dual is a superset of the ipv4, and we have all the other jobs for ipv4 ...
I'd like to hear from Ben too

[aojea]

/hold
let's wait until dual-stack goes GA, tentative this cycle, and we can switch pull-kind for pull-kind-dual

[BenTheElder]

let's wait until dual-stack goes GA, tentative this cycle, and we can switch pull-kind for pull-kind-dual

I feel like of the 3 scenarios people are most likely to have ipv4, or dual, not ipv6 and dual. Let's switch the ipv6 presubmit for dual?

[aojea]

I feel like of the 3 scenarios people are most likely to have ipv4, or dual, not ipv6 and dual. Let's switch the ipv6 presubmit for dual?

the dual job test exercises the same codepath that the ipv4, since its first ipFamily is IPv4 ... we don't have any other gate for ipv6. I prefer switching the ipv4 to dual, so we don't loose any coverage ... and gce and the others are still ipv4 only

[BenTheElder]

and gce and the others are still ipv4 only

yes, which is why I'm not thrilled to not have a closely matching kind job, we need to be able to answer the question if flakes are due to kind (or GCE!) or something else (like totally different cluster mode / tests)

[BenTheElder]

longterm I personally still lean towards GCE -> not in k/k presubmit, except maybe the moderate scale tests. we want to drive down test time and avoid testing vendors versus k8s itself.

but until then, we have to compare kind to GCE as the defacto prior presubmit.

[aojea]

we can use the periodics job to get signal, if we start to see bugs or regressions I'll reopen the debate
Thanks