Update go.mod for k8s 1.17

[justinsb]

These are now tagged with v0.17.4, so we don't need the trick of the
commented out imports any more!

[justinsb]

BTW here's a video of how to update these, except that I don't think we need to any more because it looks like upstream has (mostly?) fixed their go.mods, so now we can just use v0.17.4 instead of kubernetes-1.17.4, and that value isn't mangled by go.mod: https://asciinema.org/a/317782

[justinsb]

cc @rifelpet on the video. The other steps are to run make gomod to update vendor/, and then fix up any problems - here the problem was only a new flag that GCE cloudprovider added, that otherwise would make it into all our docs, so pretty easy this time (at least so far!)

[mikesplain]

Thanks @justinsb!

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb, mikesplain

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 [justinsb,mikesplain]

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

[rifelpet]

thanks, the video was very helpful! can you explain why this version didn't (need to) change? It seems all of the k8s.io packages are covered by replaces above, but this, kubectl, and legacy-cloud-providers below didn't change.

[justinsb]

Hmmm ... that's a good point and is just my mistake! Will hold the PR!

[justinsb]

Ah actually, I take it back...

The replace directives at the top take precedence, and we do have:

replace k8s.io/client-go => k8s.io/client-go v0.17.4

client-go started adopted a different versioning scheme though, and it looks like it isn't fully sorted out yet. That confuses go.mod which then puts some random version in the directives.

I was able to override the version in go.mod manually, so it now looks intuitive, even though that version wasn't used before.

We'll likely have to do this manually going forwards (but if we forget, it shouldn't really matter)

[rifelpet]

ah ok. and does the same apply for kubectl and legacy-cloud-providers ?

[justinsb]

/hold

[justinsb]

/unhold

[rifelpet]

seems like the answer to my last question is yes.

/lgtm

I propose we let this sit for a bit to let periodic e2e jobs run, then cherry-pick back to 1.17