Change:
config := &Config{ Host:      ts.URL, Transport: utilnet.SetTransportDefaults(transport), <del> Timeout:   100 * time.Millisecond, </del> <ins> Timeout:   1 * time.Second, </ins> // These fields are required to create a REST client. ContentConfig: ContentConfig{ GroupVersion:         &schema.GroupVersion{},

Discussion:
periodic-kubernetes-unit-test-ppc64le 16th November 2021 https://k8s- This test is by change Seems like it started being flaky from the time . Below is the trace from job: /sig node
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Proof of Flakiness: !
^^
/assign
interesting, it doesn't have any failure in all the other jobs it seems it's only flake in ppc64le maybe a golang issue?
I don't have access to a ppc64le system, but it would be good to run the test with the tool
This testgrid tab is slated for removal as the job is not maintained: Conformance tests are required to pass on ppc64le which are tracked here: But I don't think we necessarily have support for unit tests.
Yes the dashboard . But we need to find a better place for dashboard . Removal of this altogether as part of testgrid cleanup is not right! k8s unit tests would need a run on ppc64le architecture.
Is not only being able to have a job, there has to be resources, this case is a good example, the test works perfectly in x86 :/ What is the next step? Who will investigate the golang chain and the specifics of ppc64le environment?
I feel unit tests do give us a lot of confidence in the code, it's worth identifying the issues.
Completely agree, need resources to debug/identify the issues.
When I run using the stress tool the test is flaking in both ppc64le and x8664. on ppc64le:on x8664: the golang version was
yeah, that is the thing, we have this situation: same test , same golang version and it only flakes in ppc64le. It is legit to think that the architecture can be the problem here, now, who can discard that the architecture is the problem?

BTW, seems golang has some reported architecture issues that may be related EDIT wait, I didn't see it failed in x86 too :eyes:
there were some http changes in golang however, I can't reproduce it in my host :/
Is this somehow related Can you please look?
I compiled the test binary using the flag enabled. We see this flaky only when the race is enabled. Can you please try passing -race while compiling the binary for the stress tool. I followed
:/ not a single failure in 20 mins
Why was the binary for being generated when we are running stress tool for ? Please help me understand if I am missing something.
I was lazy and carried over the cli flags, but it doesn't matter, the generated binary is the same
I have seen that, there are no failures after increasing the timeout to 200 Millisecond from 100 Millisecond Before increasing the timeout: After increasing the timeout Machine information Is there any way i can find, where its been taking longer time or why its expecting some extra time.
Maybe we can just bump the timeout in the test, is not like we need such granularity and we are talking of milliseconds only .,.. , maybe something in the standard library is racing?
submitted for bumping the timeout on this test, thanks for keep pushing