Set stdin to nil for HyperV execs

[mheon]

We're seeing a bug where failed Podman commands can hang in the test suite, but somehow un-hang on STDIN activity (e.g. pressing enter). On Brent's vague suspicion that it was related to STDIN, I disabled STDIN on all execs from HyperV, and the hangs disappear. I don't know why this is, or why the hangs happen in the first place, but since this seems to work and should not have any negative consequences that I can think of, here we go.

[NO NEW TESTS NEEDED] I have no idea how to test this one.

Does this PR introduce a user-facing change?

NONE

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mheon

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

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

[mheon]

/cherry-pick v4.8

For 4.9

[openshift-cherrypick-robot]

@mheon: once the present PR merges, I will cherry-pick it on top of v4.8 in a new PR and assign it to you.

In response to this:

/cherry-pick v4.8

For 4.9

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.

[Luap99]

Stdin is nil by default and looking at the source this seems to also be the case for windows. I mean setting it explicitly to nil won't cause harm but I fail to see how this could change the behaviour in any way so I doubt it fixes anything.

[baude]

@n1hility do you mind weighing in ?

[n1hility]

@baude @mheon hmm this change shouldn't create any effect. In all of these cases exec.Command() is either called directly or indirectly just before, and exec.Command doesn't touch cmd.Stdin. Since all struct values initialize as nil, it already is nil, so all 3 of these should effectively be no-ops.

[mheon]

Doesn't seem like this is necessary, so closing