jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --- post-kubernetes-push-image-etcd n/a 2020-08-11 Started failing when merged No new versions of etcd are getting pushed until this gets fixed, when means the following PRs haven't fully taken effect: /sig api-machinery /priority critical-urgent /milestone v1.23 /assign FYI
/sig release /area release-eng
I've opened to rollback the offending commit, would like to keep this open until we can figure out the correct fix-forward
/triage accepted
was triggered by the merge of , which pushed So that's now current / includes whatever PRs linked in the description may have tried to change (excluding )
does this need promotion at all or are we good with the existing image?
/remove-priority critical-urgent /priority important-soon The job is back to passing
Recent updates are related to Debian base image update and golang upgrade. Nice to get a promotion. Good enough to use .
Yeah, looks like that the env in the build job does not search for docker CLI plugins in the path, which makes it unavailable during the run.
I think we have to set the environment variable like we already do in other build jobs, proposing the fix in
Latest test run is green:

Related discussion:
text: cd $(TEMP_DIR) && echo "ENV ETCD_UNSUPPORTED_ARCH=$(ARCH)" >> Dockerfile endif <ins> docker run --rm --privileged multiarch/qemu-user-static:$(QEMUVERSION) --reset -p yes docker buildx version BUILDER=$(shell docker buildx create --use) </ins> # And build the image <del> docker build  </del> <ins> docker buildx build  </ins> --pull  <ins> --load  --platform linux/$(ARCH)  </ins> -t $(REGISTRY)/etcd-$(ARCH):$(IMAGE_TAG)  --build-arg BASEIMAGE=$(BASEIMAGE)  --build-arg RUNNERIMAGE=$(RUNNERIMAGE)  $(TEMP_DIR) <ins> docker buildx rm $$BUILDER </ins> push: build docker tag $(REGISTRY)/etcd-$(ARCH):$(IMAGE_TAG) $(MANIFEST_IMAGE)-$(ARCH):$(IMAGE_TAG)
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --- post-kubernetes-push-image-etcd n/a 2020-08-11 Started failing when merged No new versions of etcd are getting pushed until this gets fixed, when means the following PRs haven't fully taken effect: /sig api-machinery /priority critical-urgent /milestone v1.23 /assign FYI
/sig release /area release-eng
I've opened to rollback the offending commit, would like to keep this open until we can figure out the correct fix-forward
/triage accepted
was triggered by the merge of , which pushed So that's now current / includes whatever PRs linked in the description may have tried to change (excluding )
does this need promotion at all or are we good with the existing image?
/remove-priority critical-urgent /priority important-soon The job is back to passing
Recent updates are related to Debian base image update and golang upgrade. Nice to get a promotion. Good enough to use .
Yeah, looks like that the env in the build job does not search for docker CLI plugins in the path, which makes it unavailable during the run.
I think we have to set the environment variable like we already do in other build jobs, proposing the fix in
Latest test run is green:

Related discussion:
text: - IMAGE=gcr.io/$PROJECT_ID/etcd - BUILD_IMAGE=debian-build - TMPDIR=/workspace <ins> - HOME=/root  # for docker buildx </ins> args: - '-c' - |
Code change:
configmap, like edit configmap test, and make some error and write-save, will see below when the content after edited is invalid, should not remove data , thus mean expect content below configmap 2 edit configmap make invalid No response version kubeadm <details</details<details</details<details</details
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 cli
PTAL
Hi, I am new to this project and would love to contribute. Can I work on this issue?
/sig cli

Related discussion:
text: stripped := []byte{} lines := bytes.Split(file, []byte("n")) for i, line := range lines { <del> if bytes.HasPrefix(bytes.TrimSpace(line), []byte("#")) { </del> <ins> trimline := bytes.TrimSpace(line) if bytes.HasPrefix(trimline, []byte("#")) && !bytes.HasPrefix(trimline, []byte("#!")) { </ins> continue } stripped = append(stripped, line...)
Code change:
doesn't do the same embedded resource and x-kubernetes-list-type "map" and "set" invariant validation that happens in custom resource create/update validation. Does that mean embedded objects and list-type fields under custom resource status can contain invalid data? if so, that needs to be fixed in a way that tolerates existing invalid data (ratcheting validation) Originally posted by in /sig api-machinery /kind bug /priority important-longterm
/triage accepted
I would like to collaborate for fixing the validation issue for custom resources and tolerate the existing invalid data. Could you please guide me with some code pointers or files and elaborate on how can I proceed for fixing this bug.
I haven't tested this, but something along the lines of this: we'd need tests to exercise the following scenarios on a CRD that specifies a status subresource with a list property with x-kubernetes-list-type=map and x-kubernetes-list-type=set a custom resource instance that already has duplicate items in the status property list can be updated successfully while still having duplicate items in the list (validation doesn't block an invalid → invalid status update) a custom resource instance that already has duplicate items in the status property list can be updated successfully to set unique items in the list (validation doesn't block an invalid → valid status update) a custom resource instance that does not have duplicate items in the status property list cannot be updated to set duplicate items in the list (validation blocks a valid → invalid status update)
since it's been a couple of months, i'm going to try and take a stab at this /assign
/assign
Hi k8s 1.25 Bug Triage Shadow here, just checking in to see if this is still on track for k8s 1.25? Thank you.
has stalled needing tests and a rebase
Thanks for the update.
Hello with the code freeze approaching, is this still on track for v1.25? Thanks!
not really, the status on is the same (needs tests)
/milestone clear

Related discussion:
text: "sigs.k8s.io/structured-merge-diff/v4/fieldpath" "k8s.io/apiextensions-apiserver/pkg/apiserver/schema/cel" <ins> structurallisttype "k8s.io/apiextensions-apiserver/pkg/apiserver/schema/listtype" </ins> "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/validation/field"
Code change:
doesn't do the same embedded resource and x-kubernetes-list-type "map" and "set" invariant validation that happens in custom resource create/update validation. Does that mean embedded objects and list-type fields under custom resource status can contain invalid data? if so, that needs to be fixed in a way that tolerates existing invalid data (ratcheting validation) Originally posted by in /sig api-machinery /kind bug /priority important-longterm
/triage accepted
I would like to collaborate for fixing the validation issue for custom resources and tolerate the existing invalid data. Could you please guide me with some code pointers or files and elaborate on how can I proceed for fixing this bug.
I haven't tested this, but something along the lines of this: we'd need tests to exercise the following scenarios on a CRD that specifies a status subresource with a list property with x-kubernetes-list-type=map and x-kubernetes-list-type=set a custom resource instance that already has duplicate items in the status property list can be updated successfully while still having duplicate items in the list (validation doesn't block an invalid → invalid status update) a custom resource instance that already has duplicate items in the status property list can be updated successfully to set unique items in the list (validation doesn't block an invalid → valid status update) a custom resource instance that does not have duplicate items in the status property list cannot be updated to set duplicate items in the list (validation blocks a valid → invalid status update)
since it's been a couple of months, i'm going to try and take a stab at this /assign
/assign
Hi k8s 1.25 Bug Triage Shadow here, just checking in to see if this is still on track for k8s 1.25? Thank you.
has stalled needing tests and a rebase
Thanks for the update.
Hello with the code freeze approaching, is this still on track for v1.25? Thanks!
not really, the status on is the same (needs tests)
/milestone clear

Related discussion:
text: "reflect" "testing" <ins> "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions" apiextensionsv1 "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1" structuralschema "k8s.io/apiextensions-apiserver/pkg/apiserver/schema" </ins> "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" <ins> "k8s.io/apimachinery/pkg/runtime/schema" "sigs.k8s.io/yaml" </ins> ) func TestPrepareForUpdate(t *testing.T) {
Code change:
It is unclear why the test needs the dynamic kubelet config. Need to clean it up. /sig node /priority important-soon /help Test is not a part of any testgrid. Need to understand why and return it back to the grid. Also it is marked as flaky. Need to be deflaked. unknown No response No response No response_ /sig node
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : ### Which jobs are failing? /priority important-soon /help ### Which tests are failing? 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
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
Hi, I am new to this project and would really love to start contributing and thought this might be a good start. Could you tell me a little more about this problem?
glad to have you, welcome! Some step by step you may start with: Find the test mentioned, understand what it is doing If dependency on DynamicKubeletConfig is found, try to work around them and remove that line. Try running the test locally. If you can repro flakiness - try to fix it If test passes: Try removing the and see if passes in serial tests on presubmits
Thank you so much! /assign
/cc
it had a non-op config change in the past - - I potentially missed this when removing that
so, if I'd like to fix it, what should I do?
see Since we understood item 2 - it is not needed, just remove the skipper lines. Ideally test needs to be de-flaked as well, but it it not necessarily in the scope of this change
this is a simple issue, so I tried to fix it since I've found it some days.

Related discussion:
text: "k8s.io/kubernetes/pkg/apis/scheduling" kubelettypes "k8s.io/kubernetes/pkg/kubelet/types" "k8s.io/kubernetes/test/e2e/framework" <del> e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper" </del> imageutils "k8s.io/kubernetes/test/utils/image" "github.com/onsi/ginkgo"
Code change:
PIDPressure is not set to true when the system has insufficient pid resource. PIDPressure is set to true correctly when the system is insufficient in pid resource. See cause below The max pid is not solely controlled by which is referred by . But it is also controlled by (whichever is smaller). However, they have different semantics resulting in the same constraint to how many processes/threads can be running on the system. <details</details<details</details<details</details<details</details<details</details<details</details
/sig node
I asked the same issue before,
My opinion: the minimum of and is the right number to count, for Linux. That will provide better instrumentation. If you're reserving a number of task IDs (PIDs) for system use, that minimum is the number that you're reserving from.
/triage accepted /priority important-longterm
/retitle System maximum PID inconsiderate of sysctl 'threads-max'
BTW I made a thing that might help folks test a fix: Originally I used it to create PIDs, to test whether apps cope with long PIDs. This version keeps the threads around so that you see them in .

Related discussion:
text: "syscall" "time" <del> "k8s.io/apimachinery/pkg/apis/meta/v1" </del> <ins> v1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> statsapi "k8s.io/kubelet/pkg/apis/stats/v1alpha1" )
Code change:
PIDPressure is not set to true when the system has insufficient pid resource. PIDPressure is set to true correctly when the system is insufficient in pid resource. See cause below The max pid is not solely controlled by which is referred by . But it is also controlled by (whichever is smaller). However, they have different semantics resulting in the same constraint to how many processes/threads can be running on the system. <details</details<details</details<details</details<details</details<details</details<details</details
/sig node
I asked the same issue before,
My opinion: the minimum of and is the right number to count, for Linux. That will provide better instrumentation. If you're reserving a number of task IDs (PIDs) for system use, that minimum is the number that you're reserving from.
/triage accepted /priority important-longterm
/retitle System maximum PID inconsiderate of sysctl 'threads-max'
BTW I made a thing that might help folks test a fix: Originally I used it to create PIDs, to test whether apps cope with long PIDs. This version keeps the threads around so that you see them in .

Related discussion:
text: func Stats() (*statsapi.RlimitStats, error) { rlimit := &statsapi.RlimitStats{} <del> if content, err := ioutil.ReadFile("/proc/sys/kernel/pid_max"); err == nil { if maxPid, err := strconv.ParseInt(string(content[:len(content)-1]), 10, 64); err == nil { rlimit.MaxPID = &maxPid </del> <ins> taskMax := int64(-1) // Calculate the mininum of kernel.pid_max and kernel.threads-max as they both specify the // system-wide limit on the number of tasks. for _, file := range []string{"/proc/sys/kernel/pid_max", "/proc/sys/kernel/threads-max"} { if content, err := ioutil.ReadFile(file); err == nil { if limit, err := strconv.ParseInt(string(content[:len(content)-1]), 10, 64); err == nil { if taskMax == -1 || taskMax > limit { taskMax = limit } } </ins> } } <ins> // Both reads did not fail. if taskMax >= 0 { rlimit.MaxPID = &taskMax } </ins> var info syscall.Sysinfo_t syscall.Sysinfo(&info)
Code change:
PIDPressure is not set to true when the system has insufficient pid resource. PIDPressure is set to true correctly when the system is insufficient in pid resource. See cause below The max pid is not solely controlled by which is referred by . But it is also controlled by (whichever is smaller). However, they have different semantics resulting in the same constraint to how many processes/threads can be running on the system. <details</details<details</details<details</details<details</details<details</details<details</details
/sig node
I asked the same issue before,
My opinion: the minimum of and is the right number to count, for Linux. That will provide better instrumentation. If you're reserving a number of task IDs (PIDs) for system use, that minimum is the number that you're reserving from.
/triage accepted /priority important-longterm
/retitle System maximum PID inconsiderate of sysctl 'threads-max'
BTW I made a thing that might help folks test a fix: Originally I used it to create PIDs, to test whether apps cope with long PIDs. This version keeps the threads around so that you see them in .

Related discussion:
text: type RlimitStats struct { Time metav1.Time `json:"time"` <del> // The max PID of OS. </del> <ins> // The max number of extant process (threads, precisely on Linux) of OS. See RLIMIT_NPROC in getrlimit(2). // The operating system ceiling on the number of process IDs that can be assigned. // On Linux, tasks (either processes or threads) consume 1 PID each. </ins> MaxPID *int64 `json:"maxpid,omitempty"` <del> // The number of running process in the OS. </del> <ins> // The number of running process (threads, precisely on Linux) in the OS. </ins> NumOfRunningProcesses *int64 `json:"curproc,omitempty"` }
Code change:
Add more message for no PodSandbox container when kubelet start. When error return, We need more message to solve it, contains container name and container id.
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 node
/assign

Related discussion:
text: containerList, _ := runtimeService.ListContainers(nil) for _, c := range containerList { if _, exists := podSandboxMap[c.PodSandboxId]; !exists { <del> return nil, fmt.Errorf("no PodsandBox found with Id '%s'", c.PodSandboxId) </del> <ins> return nil, fmt.Errorf("no PodsandBox found with Id '%s' for container with ID '%s' and Name '%s'", c.PodSandboxId, c.Id, c.Metadata.Name) </ins> } containerMap.Add(podSandboxMap[c.PodSandboxId], c.Metadata.Name, c.Id) }
Code change:
I've been following the official docs for kubeadm and how to set up a new cluster. The cluster is up and running but I noticed warning events when creating node port services: However, the node port does work (I see the output when accessing node ip:nodeport). Might it be related to something else than Kubernetes? There is no such warning event. Set up a fresh cluster with kubeadm and then create a service of nodeport type. No response <details</details<detailsHetzner cloud </details<details</details<detailscloud-init </details<detailscontainerd </details<detailscni=cilium csi=hetzner </details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
check with netstat or ss if there is a process listening on that port
no, I specified exact random port e.g. and checked it before with ss - it was not being used. Then I created the service, the warning occured, and after that the port was taken:
kube-proxy binds the NodePort to warn users that they may be shadowing a process, but it logs the errors if it can not bind the port
I met the same error and I confirmed the node port was not used by any other process. After looking into the code, I think this is a bug in kube-proxy that it would try to open a node port twice with same (empty) IP and port when is empty. contains and in below code.: I have created to fix it.
Awesome find. Did you figure out a work around? I am encountering this issue with this version of the image:
The error looked scaring but the nodePort should be working, as it was just caused by a duplicate port opening attempt. v1.23.5 and later releases have the fix.

Related discussion:
text: if err != nil { klog.ErrorS(err, "Failed to get node ip address matching nodeport cidrs, services with nodeport may not work as intended", "CIDRs", proxier.nodePortAddresses) } <ins> // nodeAddresses may contain dual-stack zero-CIDRs if proxier.nodePortAddresses is empty. // Ensure nodeAddresses only contains the addresses for this proxier's IP family. isIPv6 := proxier.iptables.IsIPv6() for addr := range nodeAddresses { if utilproxy.IsZeroCIDR(addr) && isIPv6 == netutils.IsIPv6CIDRString(addr) { // if any of the addresses is zero cidr of this IP family, non-zero IPs can be excluded. nodeAddresses = sets.NewString(addr) break } } </ins> // Build rules for each service. for svcName, svc := range proxier.serviceMap {