@krmayankk i believe 3/16 is the deadline to have a placeholder doc and it should also include such documentation. Let me check with the team and confirm.

same issue on EKS 1.16

I noticed there is a potential correlation with the node network I/O. I was doing some heavy query in Thanos, and it caused a network spike, and at the same time some of the pods running on the same node as thanos pods got restarted due to liveness probe timeout. It happened three times so far which made me think it's not just a coincidence.

@Jerry-Ge: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

https://github.com/containerd/containerd/blob/a72fe7da21237815731386d6b73a0e93700112f9/pkg/cri/server/instrumented_service.go#L114-L128 It doesn’t remove the pod many times, it just repeats the log

I agree we're relying to much on heroics of individual people that isn't sustainable. I think those are valid questions, but I would first like to hear from network folks with Google too.

I am not sure how to approach this, shouldn't we need valid key list for it?

As klog.InfoS function prototype is func(msg string, keysAndValues []interface{}) we can pass anything we like in keysAndValues and compile will not catch this. This led to misuse like this:

klog.V(2).InfoS("Keeping PVC", "PVC", klog.KRef(pvcNamespace, pvcName), " because it is still being used")

We would like to ensure that

• Number of arguments is uneven (msg +X * (key+value) = 1 + 2X = always uneven number)
• Argument on uneven index is always string (we should never pass a var or const as key)

https://github.com/CaoDonghui123/githubData/blob/6525b35d3012d0c47bdd20ee1707b7f20a035298/main.go#L27-L53 It doesn’t remove the pod many times, it just repeats the log

/retest

/assign @liggitt

For API approval

/hold cancel

CSI 1.4.0 has been cut https://github.com/container-storage-interface/spec/releases/tag/v1.4.0

xref https://github.com/pandas-dev/pandas/issues/39146

This basically just adds IO testing to the set of tests we run for ArrayManager. I already added skips for JSON and PyTables IO in the past, so those are still skipped now as well.

Maybe we could describe X as

The samples, as accepted by base_estimator.predict_proba (same below)

let's just merge that with the test above? (adding the new comments etc)

I think it's more important to describe what bug the fix fixes, rather than how it fixes the bug. So I'd suggest something like:

The predict and predict_proba methods of :class:`calibration.CalibratedClassifierCV can now properly be used on prefitted pipelines.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: <a href="https://github.com/kubernetes/kubernetes/pull/99393#" title="Author self-approved">chenyw1990</a> To complete the pull request process, please assign wojtek-t after the PR has been reviewed. You can assign the PR to them by writing /assign @wojtek-t in a comment when ready.

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

<details open> Needs approval from an approver in each of these files:

• pkg/kubelet/OWNERS
• test/OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":["wojtek-t"]} -->

[To be clear - I'm not trying to push sig-network to own that, i'm just trying to understand the arguments better.]

Let me share my thoughts, I'm personally trying to make all the dashboards in sig-network green, and this week I was able to sort out most of the problems, the last flake with TCP CLOSE_WAIT seems solved, and everything is acceptable except in GCE and Azure jobs. https://testgrid.k8s.io/sig-network

The dual-stack azure jobs are pending of a new agnhost image version bump, but I know there is an Azure person that is taking responsibility and will be working on fixing it: https://testgrid.k8s.io/sig-network-dualstack-azure-e2e

For GCE jobs I use to ping @prameshj or @MrHohn, and you can see that the gce dashboard is in a good state https://testgrid.k8s.io/sig-network-gce

However, there are GCE jobs that are in very bad state, failing continuously, https://testgrid.k8s.io/sig-network-ingress-gce-e2e https://testgrid.k8s.io/sig-network-ingress-gce-e2e#ingress-gce-e2e

I'm practically doing this by myself, that is a personal decision, spending some time every day to review the dashboards and addressing the "generic" failures, but my time is limited, so if this has to go under sig-network umbrella I just want to be sure that these are really needed and, if they are GCE only features, asking for some help from GCE folks.

Ok, looks like original log passed %+v with intention to dump whole container object. Passing it here also make sense.

@liggitt I have addressed/responded to the comments, and added a separate commit to move all e2e tests to use the v1 api. I have created a PR to promote e2e tests to Conformance: https://github.com/kubernetes/kubernetes/pull/84740

@hexxdump: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

Hey @Ruilkyu, may I ask you to share more information about this issue? To which server (container runtime) are you trying to connect? Which crictl version are you using?

What type of PR is this?

the max-in-flight filter takes a few milliseconds to initialize and raced the /healthz get, producing this flake:

=== RUN   TestPrepareRun
W0306 19:41:03.993313   72776 authorization.go:47] Authorization is disabled
W0306 19:41:03.994050   72776 authentication.go:40] Authentication is disabled
    genericapiserver_test.go:336: [+]ping ok
        [+]log ok
        [-]poststarthook/max-in-flight-filter failed: reason withheld
        healthz check failed
        
    genericapiserver_test.go:337: 
        	Error Trace:	genericapiserver_test.go:337
        	Error:      	Not equal: 
        	            	expected: 200
        	            	actual  : 500
        	Test:       	TestPrepareRun

https://storage.googleapis.com/k8s-gubernator/triage/index.html?pr=1&job=pull-kubernetes-unit&test=PrepareRun

/kind flake

NONE

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: <a href="https://github.com/kubernetes/kubernetes/pull/99595#issuecomment-792568581" title="Approved">cheftako</a>, <a href="https://github.com/kubernetes/kubernetes/pull/99595#pullrequestreview-601008351" title="Approved">MrHohn</a>, <a href="https://github.com/kubernetes/kubernetes/pull/99595#" title="Author self-approved">prameshj</a>

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

The pull request process is described here

<details > Needs approval from an approver in each of these files:

• staging/src/k8s.io/legacy-cloud-providers/OWNERS [cheftako]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":[]} -->

Yup, I think you might be right, thanks for the report.

Ideally we would generate the oob samples at the same place where we're generating the bagging samples (i.e. in _parallel_build_trees) to avoid reproducing the bug in the future. But that might take up a lot of memory... I guess we'll have to sample n_estimators int seed for that.

Would you like to try and provide a fix @simontindemans ?

/lgtm /approve

@fromanirh: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

/retest

@hexxdump: The following tests failed, say /retest to rerun all failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

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. I understand the commands that are listed here. </details> <!-- test report -->

I think that everything should be accessible - @freehan @bowei to confirm.

is the test testing kubernetes network or gce cloud-provider, gce ingress, ....?

Technically, many networking (and other) tests are relying on cloud-provider (e.g. all tests that exercise LoadBalanced service). So that isn't unique (do we have complaints about these tests too)? So what make ingress tests different is a separate out-of-tree controller, I guess.

[To be clear - I'm not trying to push sig-network to own that, i'm just trying to understand the arguments better.]

/assign