jiebi/CodeConvo huggingface dataset:
Code change:
NUM_ADDITIONAL_NODES=${NUM_ADDITIONAL_NODES:-} ADDITIONAL_MACHINE_TYPE=${ADDITIONAL_MACHINE_TYPE:-} <del> # Set etcd image (e.g. k8s.gcr.io/etcd) and version (e.g. v3.5.0-rc.0-0) if you need </del> <ins> # Set etcd image (e.g. k8s.gcr.io/etcd) and version (e.g. v3.5.0-0) if you need </ins> # non-default version. export ETCD_IMAGE=${TEST_ETCD_IMAGE:-} export ETCD_DOCKER_REPOSITORY=${TEST_ETCD_DOCKER_REPOSITORY:-}

Related discussion:
text: PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.
Code change:
validateEvent(strconv.Itoa(index), actualEvent, item.expect, t) } <del> logWatcher1.Stop() logWatcher2.Stop() </del> <ins> logWatcher.Stop() </ins> } sinkWatcher.Stop() }

Related discussion:
text: I wasn't able to find automatically create issue for this, but I may not know what to search for. Is our bot creating issues for unit test failures? - this failure looks to me as something in client testing libraries.
If it's exposed in JUnit output, then the bot should be making issues for it.
It's not exposed in junit due to :(
Lots of failures in , probably all this bug.
Yeah this seems to be happening a lot. Raising priority.
I thought was reverted but it's not. I'll revert it.
golang 1.6 doesn't fix the race:
Sent .
Code change:
classWait      = "wait" classImmediate = "immediate" <ins> sharedClasses = map[storagev1.VolumeBindingMode]*storagev1.StorageClass{ modeImmediate: makeStorageClass(classImmediate, &modeImmediate), modeWait:      makeStorageClass(classWait, &modeWait), } </ins> ) const (

Related discussion:
text: Add test for "on PVC add", see Test for "on PVC update" is not needed, because it has already been tested in all volume scheduling tests.
/sig
docs:
Code change:
pod := getSwapTestPod(f, qosClass, memoryRequestEqualLimit) pod = runPodAndWaitUntilScheduled(f, pod) <del> gomega.Expect(isPodCgroupV2(f, pod)).To(gomega.BeTrueBecause("cgroup v2 is required for swap")) </del> <ins> if !isPodCgroupV2(f, pod) { e2eskipper.Skipf("swap tests require cgroup v2") } </ins> gomega.Expect(getSwapBehavior()).To(gomega.Equal(types.LimitedSwap)) expectedSwapLimit := calcSwapForBurstablePod(f, pod)

Related discussion:
text: master-informing: ci-crio-cgroupv1-node-e2e-conformanceE2eNode Suite.[It] [sig-node] Swap [LinuxOnly] [NodeFeature:NodeSwap] [NodeConformance] with configuration QOS Best-effort E2eNode Suite.[It] [sig-node] Swap [LinuxOnly] [NodeFeature:NodeSwap] [NodeConformance] with configuration QOS Burstable E2eNode Suite.[It] [sig-node] Swap [LinuxOnly] [NodeFeature:NodeSwap] [NodeConformance] with configuration QOS Burstable with memory request equals to limit E2eNode Suite.[It] [sig-node] Swap [LinuxOnly] [NodeFeature:NodeSwap] [NodeConformance] with configuration QOS Guaranteed After was merged No response /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
/assign
/cc
Code change:
"k8s.io/klog" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> storage "k8s.io/api/storage/v1" apierrs "k8s.io/apimachinery/pkg/api/errors" meta "k8s.io/apimachinery/pkg/apis/meta/v1"

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: Followup to In 1.15, we can merge this commit: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign
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
Code change:
// Two different versions of the same pod will always have different RVs. return } <ins> podChanged := podAddressChanged(oldPod, newPod) // Check if the pod labels have changed, indicating a possibe // change in the service membership labelsChanged := false if !reflect.DeepEqual(newPod.Labels, oldPod.Labels) || !hostNameAndDomainAreEqual(newPod, oldPod) { labelsChanged = true } // If both the pod and labels are unchanged, no update is needed if !podChanged && !labelsChanged { return } </ins> services, err := e.getPodServiceMemberships(newPod) if err != nil { utilruntime.HandleError(fmt.Errorf("Unable to get pod %v/%v's service memberships: %v", newPod.Namespace, newPod.Name, err)) return } <del> // Only need to get the old services if the labels changed. if !reflect.DeepEqual(newPod.Labels, oldPod.Labels) || !hostNameAndDomainAreEqual(newPod, oldPod) { </del> <ins> if labelsChanged { </ins> oldServices, err := e.getPodServiceMemberships(oldPod) if err != nil { utilruntime.HandleError(fmt.Errorf("Unable to get pod %v/%v's service memberships: %v", oldPod.Namespace, oldPod.Name, err)) return } <del> services = services.Union(oldServices) </del> <ins> services = determineNeededServiceUpdates(oldServices, services, podChanged) </ins> } for key := range services { e.queue.Add(key) }

Related discussion:
text: /kind bug What happened: On a large cluster with enough pods, endpoints take as long as 10 minutes to show up after their associated pods and service are created. We believe that this is because every pod change results in an update of the addresses within the endpoint since they refer to a pod via a whose changes every time a pod change is observed. All these non-update updates eventually overwhelm the endpoint controller's queue rate limit and the queue starts to grow. While an increase in the queue's rate limit can alleviate the problem, an admin can keep a much lower limit if the non-update updates are dropped rather than processed. What you expected to happen: When a pod related to an endpoint is updated, I would expect the endpoint to update only if there is a change in the pod that relates to the endpoint, such as a change in the pod's IP address. How to reproduce it (as minimally and precisely as possible): a pod and associated service: the endpoint for changes: the watch running, and in another session, edit a pod to add a label: Then add another label on the line after the label, such as that the watched endpoint changed despite there not being any meaningful change to the fields the endpoint cares about. Anything else we need to know?: The PR addresses this issue. Environment: Kubernetes version (use ):
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig scalability
what ever happened with the effort to move leases off of Endpoints?
Code change:
configs[CheckMetadataConcealment] = Config{e2eRegistry, "metadata-concealment", "1.2"} configs[CudaVectorAdd] = Config{e2eRegistry, "cuda-vector-add", "1.0"} configs[CudaVectorAdd2] = Config{e2eRegistry, "cuda-vector-add", "2.0"} <del> configs[DebianIptables] = Config{buildImageRegistry, "debian-iptables", "v12.1.2"} </del> <ins> configs[DebianIptables] = Config{buildImageRegistry, "debian-iptables", "buster-v1.3.0"} </ins> configs[EchoServer] = Config{e2eRegistry, "echoserver", "2.2"} configs[Etcd] = Config{gcRegistry, "etcd", "3.4.13-0"} configs[GlusterDynamicProvisioner] = Config{dockerGluster, "glusterdynamic-provisioner", "v1.0"}

Related discussion:
text: What would you like to be : Have debian-iptables with iptables 1.8.5+ Why is this needed: To fix (nodelocaldns + iptables-nft) More informations Found a bug in iptables-nft, fixed in iptables 1.8.5, and now available in buster-backports https://alioth-
/sig api-machinery
ping as you did the last 2 updates
Yep, this is on my list. Will take of it next week. /sig release network /area release-eng /milestone v1.20 /assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Opened to bump the debian-iptables images in kubernetes/kubernetes. /remove-triage unresolved
Here are the digests for the new image ():
Please reopen if you run into any issues with the new images. /close
Closing this issue. <detailsIn response to : Please reopen if you run into any issues with the new images. /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
Code change:
####################### # kubectl local proxy # ####################### <del> # This next block disabled until non-racy solution to # port allocation can be found (#19999). # #  # Make sure the UI can be proxied #  start-proxy #  check-curl-proxy-code /ui 301 #  check-curl-proxy-code /metrics 200 #  check-curl-proxy-code /api/ui 404 #  if [[ -n "${version}" ]]; then #    check-curl-proxy-code /api/${version}/namespaces 200 #  fi #  check-curl-proxy-code /static/ 200 #  stop-proxy # #  # Make sure the in-development api is accessible by default #  start-proxy #  check-curl-proxy-code /apis 200 #  check-curl-proxy-code /apis/extensions/ 200 #  stop-proxy # #  # Custom paths let you see everything. #  start-proxy /custom #  check-curl-proxy-code /custom/ui 301 #  check-curl-proxy-code /custom/metrics 200 #  if [[ -n "${version}" ]]; then #    check-curl-proxy-code /custom/api/${version}/namespaces 200 #  fi #  stop-proxy </del> <ins> # Make sure the UI can be proxied start-proxy check-curl-proxy-code /ui 301 check-curl-proxy-code /metrics 200 check-curl-proxy-code /api/ui 404 if [[ -n "${version}" ]]; then check-curl-proxy-code /api/${version}/namespaces 200 fi check-curl-proxy-code /static/ 200 stop-proxy # Make sure the in-development api is accessible by default start-proxy check-curl-proxy-code /apis 200 check-curl-proxy-code /apis/extensions/ 200 stop-proxy # Custom paths let you see everything. start-proxy /custom check-curl-proxy-code /custom/ui 301 check-curl-proxy-code /custom/metrics 200 if [[ -n "${version}" ]]; then check-curl-proxy-code /custom/api/${version}/namespaces 200 fi stop-proxy </ins> ########################### # POD creation / deletion #

Related discussion:
text: I disabled a block of code in . The code was flaky (). Suggest one of the following solutions: this type of test coverage to an e2e, or VM or docker based test, where there are no port conflicts. kubectl proxy command to have a mode where it will pick a port for you, trying until it finds one. the test loop to allow failure of kubectl proxy command when it exits with a certain error code that means it could not get a port, and retries until it gets one.
Fixed in ?
No, not fixed:
We still need to reenable this code. I was unaware that it'd been disabled.
I made a reversion PR.
Code change:
if na, ok := nt.tree[zone]; ok { for _, nodeName := range na.nodes { if nodeName == n.Name { <del> klog.Warningf("node %v already exist in the NodeTree", n.Name) </del> <ins> klog.Warningf("node %q already exist in the NodeTree", n.Name) </ins> return } }

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) Increase the log level of info logs to "v=2" when the scheduler or a node from its cache. 2) Increase the log level of info logs to "v=2" when the scheduler can't schedule a pod , , and add a log message for 2) report memory/cpu status of . Why is this needed: With cluster autoscaler now being used in production by some vendors, we want to have more visibility to events that could be related to the auto scaler to help debug customer issues. /sig scheduling /priority important-soon /assign
GitHub didn't allow me to assign the following users: congliu01. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : <!-- Please only use this template for submitting enhancement requests --1) Increase the log level of info logs to "v=2" when the scheduler or a node from its cache. 2) report memory/cpu status of . Why is this needed: With cluster autoscaler now being used in production by some vendors, we want to have more visibility to events that could be related to the auto scaler to help debug customer issues. /priority important-soon /assign </details
will consider this assigned to you.
/assign
Code change:
result += stat.RestartCount } } <ins> if *job.Spec.BackoffLimit == 0 { return result > 0 } </ins> return result >= *job.Spec.BackoffLimit }

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: If you have a JobSpec and set with in 1.9.x, then the job will start a pod and never restart it regardless of success of failure. In 1.10.x, a job spec with and , k8s does not start any pods at all. We had to set in order to get the pod to run. The wording in the docs suggest that should only take effect when the pod is finished/or failed. It shouldn't cap starting the initial pod. How to reproduce it (as minimally and precisely as possible): Run the following job spec in 1.9.x and 1.10.x: Anything else we need to know?: The docs links this existing ticket saying is ineffective with , but the ticket talks about restarting too many times, not never starting a pod. Given this issue was slightly different, I originally did not think it was a backoffPolicy bug. Environment: Kubernetes version (use ): Tested on 1.9.7 and 1.10.6 Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Fedora 28
/sig apps
We've been hit by this too, in v1.10.6. It seems to me that with the current behavior, a value of doesn't really make any semantic sense. I think the problem comes from the function in : called here: if is , then will end with .
Code change:
switch { case storage.IsNotFound(err): return errors.NewNotFound(qualifiedResource, "") <del> case storage.IsUnreachable(err): </del> <ins> case storage.IsUnreachable(err), storage.IsRequestTimeout(err): </ins> return errors.NewServerTimeout(qualifiedResource, "list", 2) // TODO: make configurable or handled at a higher level case storage.IsInternalError(err): return errors.NewInternalError(err)

Related discussion:
text: It is possible to issue a list request which exceeds the duration set by the request-timeout apiserver flag. The request-timeout flag does not appear to be enforced when the apiserver is decoding the response from etcd. Specifically, listing a large number of CRDs from etcd can result in high request latency from using json encoding compared to protobuf encoding. While overall etcd latency is low, the overall listing from storage latency may be over the 1 minute timeout, particularly if the apiserver needs to fetch multiple pages from etcd. We expected the list requests to be subject to the duration specified by the request-timeout flag when this latency is coming from the listing from storage phase of the request. Create 4000 CRs and list all the objects from etcd in 2 pages of 2000 objects. If the time to list 1 page + decode takes around 50s, listing 2 pages will result in the listing from storage phase of the request taking around 1 minute and 40s before the request fails and the client is returned a 500 response code. Logs for apiserver Trace message: Audit log entry: Related issue for supporting protobuf for CRDs: <details</details<detailsAWS </details<details</details<details</details<details</details<details</details
/sig api-machinery CC:
Interesting.. - do you know where exactly we stuck? In the call to storage: we pass the context that has timeout set, so that shouldn't hang. OTOH, for the processing part: (a) I don't know if transformer honors the context - it probably depends on the implementation (b) but the decoding (appendListitem) certainly isn't honoring the context So (b) might definitely be a problem, even independently from from the transformer So I guess what I'm saying is that if listing from etcd finishes fast but the decoding is what takes most of time, then what you described can certainly be a problem. But is that the thing you're observing?
Yes, that is our understanding. Specifically, that the decoding which occurs in appendListItem doesn't respect the context: As a separate follow-up, it would be useful to include decoding time, or at least the overall listing from storage time, as a separate latency annotation, given the audit log entry is only capturing this latency as part of
+1.
Code change:
switch { case storage.IsNotFound(err): return errors.NewNotFound(qualifiedResource, "") <del> case storage.IsUnreachable(err): </del> <ins> case storage.IsUnreachable(err), storage.IsRequestTimeout(err): </ins> return errors.NewServerTimeout(qualifiedResource, "list", 2) // TODO: make configurable or handled at a higher level case storage.IsInternalError(err): return errors.NewInternalError(err)

Related discussion:
text: We need more granular latency tracker especially on the latency spent on decoding. Right now, it only captures etcd round trip and transformer latency.
I would be supportive for both and would be happy to review it if someone opens up a PR for it.
/triage accepted
/assign
/reopen I think we need to reopen it to document how we resolved the unit test failures brought on by adding it
Reopened this issue. <detailsIn response to : /reopen I think we need to reopen it to document how we resolved the unit test failures brought on by adding it 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
Code change:
tree      map[string]*nodeArray // a map from zone (region-zone) to an array of nodes in the zone. zones     []string              // a list of all the zones in the tree (keys) zoneIndex int <del> NumNodes  int </del> <ins> numNodes  int </ins> mu        sync.RWMutex }

Related discussion:
text: Description: , part of the is exporting a field which allows to modify its value externally. This also means that this field is not thread-safe. Solution: Expose a method that returns this value in a thread-safe way and do not export the field. /kind bug /sig scheduling
Code change:
podInPendingStateTimeout  = time.Second * 60 // how long to wait for a pod to stay in pending state ) <del> var _ = ginkgo.Describe("[sig-node] DRA [Feature:DynamicResourceAllocation]", func() { </del> <ins> var _ = ginkgo.Describe("[sig-node] DRA [Feature:DynamicResourceAllocation][NodeAlphaFeature:DynamicResourceAllocation]", func() { </ins> f := framework.NewDefaultFramework("dra-node") f.NamespacePodSecurityEnforceLevel = admissionapi.LevelBaseline

Related discussion:
text: sig-node : DRA related tests are failing and 2 other DRA related tests. Both jobs started failing on 7th June As per the logs DRA plugin is not getting registered to kubelet Jobs started failing after merging As per , CDI is not available out of the box for containerd which may be the reason for failure of the jobs. /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
/cc
/cc
Looks like I shouldn't have labeled DRA Node tests as NodeFeature. However, re-labeling it NodeAlphaFeature would not work either - would start to fail. I'm going to remove . This should help.
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
Not fixed yet, pending
Code change:
command: - /bin/bash - -c <del> - /opt/kube-addons.sh 1>>/var/log/kube-addon-manager.log 2>&1 </del> <ins> - exec /opt/kube-addons.sh 1>>/var/log/kube-addon-manager.log 2>&1 </ins> resources: requests: cpu: 5m

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When kube-apiserver's livenessProbe suggests that pod is unhealthy, kubelet tries to kill its container with 30 seconds grace period. The container is killed ungracefully with SIGKILL when grace period passes. This happens each time. What you expected to happen: I expected that SIGTERM will be passed to kube-apiserver which will try to gracefully stop before 30 seconds pass (at least in some cases). How to reproduce it (as minimally and precisely as possible): Inject kube-apiserver failure (e.g. ) Watch kubelet logs for container's death You will see that container is killed after 30 seconds each time Anything else we need to know?: I believe the problem is that in kube-apiserver.manifest uses '/bin/sh -c CMD' as a PID1 process which doesn't pass SIGTERM signals to child process. See Environment: Kubernetes version (use ): v1.7.11
/sig node
Looks like without the pipe command will have to be removed which will make the logs hard to track. There is indeed some which makes kube-apiserver run in background and trapping SIGTERM then send a SIGTERM to apiserver's PID.
I think this is the case for all our components, not just kube-apiserver. - FYI
How about using 'exec'-based solution suggested here: In our case it means prepending 'exec': I did changed this in my cluster and the process seems to meet requirements: fd/1 and fd/2 are redirected to /var/log/kube- container is killed instantaneously If everyone is fine with such a solution, I can prepare PR adding 'exec ' in front of all kubernetes/cluster/saltbase/salt/kube-apiserver/*.manifest using '/bin/sh -c CMD' pattern.
Not sure if understand what you mean. Before there was no logs, so /bin/sh -c wasn't needed. -based solution seems to have all required properties. What is your concern about using it?
Umm. just ignore my previous comment. I just tried prepending and it works fine for me.