Pickup kind commit that fixes node image building

[msau42]

Tested new kind version in kubernetes-csi/csi-driver-host-path#106

Fixes: kubernetes-csi/csi-release-tools#38

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: msau42

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:

• config/jobs/kubernetes-csi/OWNERS [msau42]

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

[msau42]

/assign @davidz627

[davidz627]

why is there a TODO on all of these - if necessary please add exit criterea or tracking bug for context

[msau42]

Using a specific commit of kind is a workaround until kind releases a new version. Updated with bug reference

[davidz627]

/lgtm

[k8s-ci-robot]

@msau42: Updated the job-config configmap in namespace default using the following files:

• key csi-driver-host-path-config.yaml using file config/jobs/kubernetes-csi/csi-driver-host-path/csi-driver-host-path-config.yaml

In response to this:

Tested new kind version in kubernetes-csi/csi-driver-host-path#106

Fixes: kubernetes-csi/csi-release-tools#38

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.

[pohly]

As a stop-gap measure this is okay, but I think it's cleaner to let individual projects pick the version of kind that works for them and what they need kind for.

[msau42]

As a stop-gap measure this is okay, but I think it's cleaner to let individual projects pick the version of kind that works for them and what they need kind for.

I actually prefer the model where all versions are defined in configs and the prow.sh script itself has as few versions encoded in it as possible. It makes it a lot simpler to apply changes consistently across all repos. I don't see a strong use case for having different repos use different versions and it has not come up as a need for us yet.

If different repos really want different configs, then they can specify that here.

[pohly]

Michelle Au <notifications@github.com> writes:

I actually prefer the model where all versions are defined in configs and the prow.sh script itself has as few versions encoded in it as possible. It makes it a lot simpler to apply changes consistently across all repos.

There are two sides of the coin here. When moving configuration into the job definition, then it becomes harder to keep the configuration consistent with the source code. If you ever get into a situation where source code and configuration need to be changed in lock-step, then merging is blocked: the source code might fail with the current test configuration and thus cannot be merged. The test configuration in test-infra cannot be merged either because then other PRs in the project fail. It also becomes harder to do maintenance releases. Old branches of a project may need a different test configuration than master, so you would have to start defining different jobs for different branches.