jiebi/CodeConvo huggingface dataset:
Code change:
Labels: labels, }, Spec: api.PodSpec{ <del> Containers: []api.Container{c}, </del> <ins> Containers:                    []api.Container{c}, TerminationGracePeriodSeconds: &gracePeriod, </ins> }, }, },

Related discussion:
text: OK then, let's add a timeout and test both DROP and REJECT-- no sort of network problem should hang a component.
I think it didn't hang. It just that the kubelet was retrying too slow and sometimes it fit test timeout, sometime it didn't.
Could we reduce the timeout to make it always fit the test timeout? , Filip Grzadkowski
I guess we can. I'll try tomorrow.
It seems we have a new type of failure: It seems that kubelet on a machine where network is blocked doesn't notice new pod. After reading logs I assume that kubelet doesn't notice that the watch is broken and doesn't try to relist everything. It notices new pod only after watch timeout.
Ugh, I hope we don't have to start sending watch heartbeats.
It seems that all recent failures are with the following error: which means the reason is here: - can you please take a look or delegate?
I did some more debugging of it. I was looking into this failure: There is something strange happening here: run performTemporaryNetworkFailure: succesfully block the load from kubelet: the succesfully wait for node to become not ready: some time nodecontroller successfully removes the pod: replication controller creates a new pod: here is something I don't undertand - because of some reason, the test doesn't observe that the pod actually disappeared. - any thoughts on it?
BTW - this is exactly the same situation in:
OK - I think this is related to default 30s deletion grace period.
Yes - it seems that this is exactly the case. I will send out PR fixing this out for review.
I'm reopening it for tracking. If there won't be any failures within next few days - I will move the test back from flaky and close this issue.
Thanks for fixing, .
It seems that the main issue is fixed. However, there was one failure in the last 30 runs: in which one pod simply didn't started (and it was "preparation" for the test, not the test itself).
During next 2 days there was exactly one more failure of this test: it is exactly the same as the previous one. However, those are duplicates of So I'm going to move this test out of flaky suite.
Code change:
"k8s.io/kubernetes/pkg/client/cache" client "k8s.io/kubernetes/pkg/client/unversioned" "k8s.io/kubernetes/pkg/controller" <ins> "k8s.io/kubernetes/pkg/runtime" </ins> "k8s.io/kubernetes/pkg/securitycontext" <ins> utiltesting "k8s.io/kubernetes/pkg/util/testing" </ins> ) var (

Related discussion:
text: The test is in flaky suite and no one seems to care. We need an owner for this test. cc Last failure log:
do you think you can take a look at this?
This is happening because of a bad assumption. The assumption is: if the reflector's store is consistent with etcd, the store given back to clients of the framework.Controller is too. I'd really like a general fix applicable to all controllers for this problem, but fixing it just for the RCs is pretty easy. In more detail: This function reports when the reflector has listed from apiserver. But the store given to the reflector is the fifo of the framework.Controller. The store given back to the caller is still not consistent, and will not be till the framework.Controller puts all the objects from the fifo into the client state store (). The rc specific fix: Before starting the rc manager, seed the expectations store with an expectation like {rc:foo, adds: foo.Status.Replicas, deletes:0}. This will wait for status.Replicas number of ADD events till a timeout. The general fix: Somehow expose this through framework.Controller.HasSynced (clients don't care about the fifo anyway, shouldn't it just be an implementation detail?) ideas? cc'ing people who have written controllers that might be interested I don't think this (and generally anything flaky for 1 release) is a p0, I can fix it if you don't mind dealing with the flakes till I've cleared things off my plate. I'd be more than happy to review a fix.
Well, it's a P0 because test is flaky. E.g last run:
- did you have chance to look into it?
The "DaemonRestart" tests are still labeled at . I will send a PR to promote them.
are you still planning to send aPR to promote the DaemonRestart tests out of flaky? I think this is the right thing to do.
Ack; sorry, I lost this in the muck.
Code change:
## Requirements 1. Docker, using one of the following configurations: <del> * **macOS** Install Docker for Mac. See installation instructions [here](https://docs.docker.com/docker-for-mac/). </del> <ins> * **macOS** Install Docker for Mac. See installation instructions [here](https://docs.docker.com/desktop/install/mac-install/). </ins> **Note**: You will want to set the Docker VM to have at least 8GB of initial memory or building will likely fail. (See: [#11852]( http://issue.k8s.io/11852)). * **Linux with local Docker**  Install Docker according to the [instructions](https://docs.docker.com/installation/#installation) for your OS. * **Windows with Docker Desktop WSL2 backend**  Install Docker according to the [instructions](https://docs.docker.com/docker-for-windows/wsl-tech-preview/). Be sure to store your sources in the local Linux file system, not the Windows remote mount at `/mnt/c`.

Related discussion:
text: The link in the following sentence is incorrect macOS Install Docker for Mac. See installation instructions . It redirects to instead of The link should get redirected to Navigate to Click on the hyperlink in the below section macOS Install Docker for Mac. See installation instructions . N/A N/A N/A N/A N/A N/A N/A
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
/assign
/sig contributor-experience
Code change:
t.objects[gvr][namespacedName] = obj for _, w := range t.getWatches(gvr, ns) { <del> w.Add(obj) </del> <ins> // To avoid the object from being accidentally modified by watcher w.Add(obj.DeepCopyObject()) </ins> } return nil

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --Hello, Found a potential data race in testing. There is a test If we update it like this (we actually can do it ): If watcher updates received object we get a data race. No data race My suggestion: send copy of object here:
/sig api-machinery
/cc /triage accepted Do you remember if we fixed similar issues before?
Hi ,The code avoiding data race seems to already exist If you commented the code on above, the following test case will pass (because of data race), so I think there is no data race in the code : )
Hi Did you run my test with flag? Of course if I comment there will be data race. But let's take a look at: We store in and do with the same . So, watcher receives that is stored in map. we call we take the same from : Therefore, if watcher modifies received in another goroutine we have data race. Output:
Hi You're right ,thank you for solving my confusion. One solution could be to copy of , I will try to fix it.
Code change:
) func (c *FakeEvictions) Evict(eviction *policy.Eviction) error { <del> action := core.GetActionImpl{} action.Verb = "post" </del> <ins> action := core.CreateActionImpl{} action.Verb = "create" </ins> action.Namespace = c.ns action.Resource = schema.GroupVersionResource{Group: "", Version: "v1", Resource: "pods"} action.Subresource = "eviction" <del> action.Name = eviction.Name </del> <ins> action.Object = eviction </ins> _, err := c.Fake.Invokes(action, eviction) return err }

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: I'm trying to test Eviction functionality in my program, but running into some inconsistencies around how Evictions are handled in the fake SimpleClient in the client-go testing functionality. Most notably, creates a different from , and both are missing information. issues a with set to (seems to be the only Fake that has this mismatch) on the subresource of . It is missing all the extra information in the eviction, i.e. the . issues a on the subresource of the resource. This is wrong, because aren't created, they're only posted and handled immediately. The Action is missing a Namespace. What you expected to happen: I want to be able to add my own reactor to the SimpleClient to handle this special case. I propose we change both cases to a with set to the . This will ensure it's not handled by the current SimpleClient ObjectReaction, and makes it so users can implement whatever they want themselves. I'd be happy to make a PR with these changes. How to reproduce it (as minimally and precisely as possible): Output: Environment: git revision of : <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
POST requests are create requests. It doesn't matter if the object is persisted or not.
/sig api-machinery
cc
Code change:
name = "all-srcs", srcs = [ ":package-srcs", <ins> "//pkg/kubelet/apis/kubeletconfig/fuzzer:all-srcs", </ins> "//pkg/kubelet/apis/kubeletconfig/scheme:all-srcs", "//pkg/kubelet/apis/kubeletconfig/v1alpha1:all-srcs", "//pkg/kubelet/apis/kubeletconfig/validation:all-srcs",

Related discussion:
text: Solution: I will add one.
/cc
xref
Thanks for sending a PR so quickly!
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code slush, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: If this issue is not resolved or labeled as by Wed, Nov 22 it will be moved out of the v1.9 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Code change:
current-release-pr current-replicas daemonset-lookup-cache-size <ins> data-dir </ins> default-container-cpu-limit default-container-mem-limit delay-shutdown

Related discussion:
text: ci-kubernetes-e2e-gce-device-plugin-gpu.Overall ci-kubernetes-e2e-gce-device-plugin-gpu.Pod kubetest.Up Intermittently since 02/23 No response No response /sig testing /sig release
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
/cc /sig node BTW, would you help to confirm if this is a release cut blocker? We plan to release 1.30.0-alpha.3 on Tuesday 27th February 2024.
It passed! Maybe it was some infra issues?
Failed again. /sig k8s-infra
Many recreating of nodes in log.
This is caused by infra flaky.
The problem is
This job only runs one test and GPU instances are hard to find we don’t need many of those instances for this job, can we please change this job to only use 2 workers?
/cc
tests failed in a recent run. It failed the first time. The Job failure now changed to test case failing today. It failed 4 times in a row.
/assign
I launched a test run, logged into the master node and took the kubeconfig and found the following: Relevant bit
Link some related updates recently on this job.
The error above in is weird to me. It said No firmware image found . In successful run before, like (02-27), there are no such failure logs. failure in only kubelet log shows the pod crashed and restarted for many times. No pod log or containerd log.
After , the CI is not always failing now and 4 in a row.
/close
Closing this issue. <detailsIn response to : /close Instructions 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
/reopen as keeps flaking
Reopened this issue. <detailsIn response to : /reopen as keeps flaking Instructions for interacting with me using PR comments are available .
Code change:
current-release-pr current-replicas daemonset-lookup-cache-size <ins> data-dir </ins> default-container-cpu-limit default-container-mem-limit delay-shutdown

Related discussion:
text: If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The problem is different with the failure after the revert. We(release signal team) plan to open an issue for the flake later. (Probably, we should open that one and then close on behalf of that new issue later.)
Feel free to close it then. However, it failed 3 times out of last 4 runs. It's more a failure than a flake in my opinion. If doesn't help/ not appropriate, I'd suggest to revert installer and image changes
comment is clear about the root cause, we have a problem installing the drivers, can you redirect this issue if you think is a bug?
After was merged, there are 6 failure in last 24 run. Tab stats: 8 of 10 (80.0%) recent columns passed (258 of 262 or 98.5% cells) The Flaky rate is lower.
Code change:
"golang.org/x/net/websocket" <ins> "encoding/json" </ins> v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/runtime/schema" </ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/apimachinery/pkg/watch" <ins> "k8s.io/client-go/dynamic" </ins> "k8s.io/client-go/tools/cache" watchtools "k8s.io/client-go/tools/watch" podutil "k8s.io/kubernetes/pkg/api/v1/pod"

Related discussion:
text: [x] Original approval issue: - Reverted due to flakes [x] Two weeks soak end date: 20 November 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still some remaining Pod endpoints which are untested. a Pod with a static label the Pod with a new Label and updated data the Pod to ensure it's patched the Pod's status the Pod's status Ready condition to False the Pod's status to check if Ready is False all Pods in all Namespaces find the Pod(1) ensure that the Pod is found and is patched Namespaced Pod(1) via a Collection with a LabelSelector the Pod to check that it's deleted Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/reopen Test PR Merge Promotion PR to be created next
Reopened this issue. <detailsIn response to : /reopen Test PR Merge Promotion PR to be created next Instructions 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
reverted by due to flaky test
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/reopen PR on test grid for 2 weeks before promotion to conformance
Reopened this issue. <detailsIn response to : /reopen PR on test grid for 2 weeks before promotion to conformance Instructions 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
/triage accepted
Code change:
return selector.PodSelectorMatches } <del> // NodeMatchesNodeSelectorTerms checks if a node's labels satisfy a list of node selector terms, </del> <ins> // nodeMatchesNodeSelectorTerms checks if a node's labels satisfy a list of node selector terms, </ins> // terms are ORed, and an emtpy a list of terms will match nothing. <del> func NodeMatchesNodeSelectorTerms(node *api.Node, nodeSelectorTerms []api.NodeSelectorTerm) bool { </del> <ins> func nodeMatchesNodeSelectorTerms(node *api.Node, nodeSelectorTerms []api.NodeSelectorTerm) bool { </ins> for _, req := range nodeSelectorTerms { nodeSelector, err := api.NodeSelectorRequirementsAsSelector(req.MatchExpressions) if err != nil {

Related discussion:
text: I just noticed you forgot to register the image locality priority function in in I also missed it when I reviewed your PR. I have fixed this in . But it would be great if you could figure out a mechanism that would ensure that all predicate/priority functions that are tested (you can assume they will always live under ) are registered, and fail the test if not. That will allow us to prevent this mistake in the future.
Thanks! Will fix this soon!
Seems need to wait for in before I send PR? Otherwise this test will always fail ...
Code change:
if want == "" { want = "<nil>" } <del> if got := fmt.Sprintf("%v", err); got != want { </del> <ins> if got := fmt.Sprintf("%v", err); !strings.Contains(got, want) { </ins> t.Errorf("wrong error for message %q: want=%q, got=%q", test.message, want, got) } }

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Below k8s UT fail when run with master-golang. TestCheckpointStateRestore/RestorecheckpointwithinvalidJSON error:=== RUN TestCheckpointStateRestore/RestorecheckpointwithinvalidJSON I1124 05:38:14. ] [cpumanager] initializing new in-memory state store unexpected error while creatng checkpointState: could not restore state from checkpoint: json: unexpected end of JSON input, please drain this node and delete the CPU manager checkpoint file "/tmp/cpumanagerstatetest479660663/cpumanagercheckpointtest" before restarting Kubelet --- FAIL: TestCheckpointStateRestore/RestorecheckpointwithinvalidJSON (0.00s) TestStrategicMergePatchInvalid error:=== RUN TestStrategicMergePatchInvalid expected "invalid character 'b' looking for beginning of value", got "json: invalid character 'b' looking for beginning of value" --- FAIL: TestStrategicMergePatchInvalid (0.00s) TestJSONPatch error:=== RUN TestJSONPatch invalid-syntax: expected error invalid character 'i' looking for beginning of value, but got json: invalid character 'i' looking for beginning of value --- FAIL: TestJSONPatch (0.00s) TestV4ErrorDecoder expandless error:=== RUN TestV4ErrorDecoder wrong error for message "{": want="error stream protocol error: unexpected end of JSON input in "{"", got="error stream protocol error: json: unexpected end of JSON input in "{"" --- FAIL: TestV4ErrorDecoder (0.00s What you expected to happen: The tests should pass with no error. How to reproduce it (as minimally and precisely as possible): a stable version of golang installed master go from upstream git clone cd go/src cd ../.. cp -r ./go /usr/local export PATH=/usr/local/go/bin:$PATH kubernetes repo and run the unit tests. () Anything else we need to know?: These failures are occurring due to mismatch of error messages between upstream go and the k8s tests.
Code change:
if want == "" { want = "<nil>" } <del> if got := fmt.Sprintf("%v", err); got != want { </del> <ins> if got := fmt.Sprintf("%v", err); !strings.Contains(got, want) { </ins> t.Errorf("wrong error for message %q: want=%q, got=%q", test.message, want, got) } }

Related discussion:
text: There is an addition "json:" prefix to SyntaxError messages after this below commit: Environment: Kubernetes version (use ): latest source code from upstream Cloud provider or hardware configuration: OS (e.g: ): "CentOS Linux 8 (Core)" Kernel (e.g. ): Linux rajalakshmi-workspace 4.18.0-193.19.1.el82.ppc64le SMP Mon Sep 14 14:48:04 UTC 2020 ppc64le ppc64le ppc64le GNU/Linux Install tools: [root go]# go version go version devel + Fri Nov 20 00:54:43 2020 +0000 linux/ppc64le [root go]# Network plugin and version (if this is a network-related bug): Others:
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
/sig testing
will fix it in Go 1.16 as release-blocker.
I would fix the test here to be more tolerant. exact string matches on error messages aren't really an API… I would not expect that to block the golang release
Agree too, we can think about having a substring match to avoid these issues instead!
/assign Lets see if we can fix this in the k8s tests
Code change:
apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/intstr" <ins> "k8s.io/apimachinery/pkg/util/uuid" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/kubernetes/test/e2e/framework" e2epod "k8s.io/kubernetes/test/e2e/framework/pod" imageutils "k8s.io/kubernetes/test/utils/image" "github.com/onsi/ginkgo" <ins> "k8s.io/apimachinery/pkg/types" </ins> ) func extinguish(f *framework.Framework, totalNS int, maxAllowedAfterDel int, maxSeconds int) {

Related discussion:
text: This issue proposes the writing of a new test for the API endpoint with the intention of promoting it to Conformance. This issue contains a very masic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to this query, there is only one API endpoint which is for Namespace that isn't being covered. We selected patchCoreV1Namespace to write a test for. Dependencies: The mock test: If a test with these calls is build and merged, conformance will go up by 1 endpoint.
/sig testing /sig architecture /area conformance
Code change:
cloud: gce EOF <ins> DOCKER_OPTS="" if [[ -n "${EXTRA_DOCKER_OPTS-}" ]]; then DOCKER_OPTS="${EXTRA_DOCKER_OPTS}" fi </ins> # Decide if enable the cache <del> if [[ "${ENABLE_DOCKER_REGISTRY_CACHE}" == "true" ]]; then </del> <ins> if [[ "${ENABLE_DOCKER_REGISTRY_CACHE}" == "true" ]]; then </ins> REGION=$(echo "${ZONE}" | cut -f 1,2 -d -) echo "Enable docker registry cache at region: " $REGION <del> DOCKER_OPTS="--registry-mirror="https://${REGION}.docker-cache.clustermaster.net"" </del> <ins> DOCKER_OPTS="${DOCKER_OPTS} --registry-mirror='https://${REGION}.docker-cache.clustermaster.net'" fi </ins> <del> cat <<EOF >>/etc/salt/minion.d/grains.conf </del> <ins> if [[ -n "{DOCKER_OPTS}" ]]; then cat <<EOF >>/etc/salt/minion.d/grains.conf </ins> docker_opts: $DOCKER_OPTS EOF fi

Related discussion:
text: 0/8 is with a company's intranet, so it can be insecure. This is similiar to "For GCE, allow insecure registries anywhere in 10.0.0.0/8" Thanks!
Linking to and .
This was