jiebi/CodeConvo huggingface dataset:
Change:
w.Write(LEVEL_2, "NodeName:t%sn", nodeNameText) zoneText := "<unset>" <del> if endpoint.NodeName != nil { </del> <ins> if endpoint.Zone != nil { </ins> zoneText = *endpoint.Zone } w.Write(LEVEL_2, "Zone:t%sn", zoneText)

Discussion:
<!-- 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 --panic as below when an Endpoint doesn't have zone. should print zone as if an Endpoint's zone is unset. not set "" for Nodes. Pods and export them as a service. kubectl to describe the corresponding EndpointSlice. Kubernetes version (use ): v1.21.0 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: 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 network /sig cli /assign
Change:
verbs:     "get,watch,list", resources: "pods,deployments.extensions", expectedRole: &rbac.Role{ <ins> TypeMeta: v1.TypeMeta{APIVersion: "rbac.authorization.k8s.io/v1", Kind: "Role"}, </ins> ObjectMeta: v1.ObjectMeta{ Name: roleName, },

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Upgraded Kubectl to version 1.10.0 and now the flag on the creation of a docker-registry secret doesn't print out resulting in the following error: What you expected to happen: I expect the output to have a attribute in the YAML output. How to reproduce it (as minimally and precisely as possible): Here is an example you can run in bash of this not working: The output is: My exact shell code I'm running on the CI server is this Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: 3 on AWS managed with KOPS OS (e.g. from /etc/os-release): Alpine Linux on my CI server, MacOS on my main machine Kernel (e.g. ): Darwin Kernel Version 17.4.0
/sig CLI
cc
/status approved-for-milestone
/assign
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : 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
fyi
The issue appears to be with the command, not with : Will look into this
fix is in
No, the output of is missing kind/apiVersion.
thanks, just saw the PR
Change:
if len(containers) > 0 { firstContainer, containers = containers[0], containers[1:] } <del> _, err := fmt.Fprintf(w, "%st%st%st%st%st%sn", </del> <ins> _, err := fmt.Fprintf(w, "%s/%st%st%st%st%st%sn", </ins> pod.Name, <ins> pod.Status.PodIP, </ins> firstContainer.Name, firstContainer.Image, podHostString(pod.Status.Host, pod.Status.HostIP),

Discussion:
From IRC ... Currently kubectl get pod <idonly list Host IP on which the pod bounds to, there is no PodIP information. The only way for the user to know PodIP is run the same command with "-o json" flag. This is confusion to the user. cc
Already working on a PR for this.
Yay.
Change:
// ref: #101697, #94626 - ImagePullSecrets are allowed to have empty secret names // which would fail the 2-way merge patch generation on Pod patches // due to the mergeKey being the name field <del> name: "Should update pod conditions successfully on a pod Spec with secrets with empty name", </del> <ins> name:   "Should update pod conditions successfully on a pod Spec with secrets with empty name", client: clientsetfake.NewSimpleClientset(), </ins> pod: v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Namespace: "ns", <del> Name:      "pod2", </del> <ins> Name:      "pod1", </ins> }, Spec: v1.PodSpec{ // this will serialize to imagePullSecrets:[{}]

Discussion:
If there is a connection failure when updating the Pod status, we don't retry. Furthermore, due to , we won't have another chance until much later. The problem is that if we don't mark the Pod as Unschedulable, other controllers (such as cluster-autoscaler) wouldn't react to these pods. We should have stronger guarantees to mark a Pod as Unschedulable. You need an unschedulable Pod (for example, a Pod with a non matching node affinity) and a flaky connection to apiserver. No response master This is particularly problematic in 1.24, due to . Any <details</details<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 scheduling
That is bad, retrying in place on transient errors should probably be ok.
I'll address it. /assign
Thanks!
Change:
go.uber.org/atomic v1.4.0/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE= go.uber.org/atomic v1.7.0 h1:ADUqmZGgLDDfbSL9ZmPxKTybcoEYHgpYfELNoN+7hsw= go.uber.org/atomic v1.7.0/go.mod h1:fEN4uk6kAWBTFdckzkM89CLk9XfWZrxpCo0nPH17wJc= <ins> go.uber.org/automaxprocs v1.5.2 h1:2LxUOGiR3O6tw8ui5sZa2LAaHnsviZdVOUZw4fvbnME= go.uber.org/automaxprocs v1.5.2/go.mod h1:eRbA25aqJrxAbsLO0xy5jVwPt7FQnRgjW+efnwa1WM0= </ins> go.uber.org/multierr v1.1.0/go.mod h1:wR5kodmAFQ0UK8QlbwjlSNy0Z68gJhDJUG5sjR94q/0= go.uber.org/multierr v1.6.0 h1:y6IPFStTAIT5Ytl7/XYmHvzXQ7S3g/IeZW9hyZ5thw4= go.uber.org/multierr v1.6.0/go.mod h1:cdWPpRnG4AhwMwsgIHip0KRBQjJy5kYEpYjJxpXp9iU=

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : should detect the appropriate GOMAXPROCS based off of the cpu limit supplied to the pod. Why is this needed: If not, test failures can occur (e.g. ) where GOMAXPROCS defaults to the number of cpus on the machine, while the cpu limit is actually far less. Too many compile/test processes launch, and any timing tests can become flaky. The end result is that running the test jobs on a node with more CPUs can make it flaky when running the test on a node with fewer CPUs cleanly passes. It's possible to set GOMAXPROCS=cpu limits in test jobs to avoid this, but it would be nicer if would autodiscover and set GOMAXPROCS appropriately.
/sig testing /sig k8s-infra
/transfer kubernetes
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 dims
xref:
This is already done, which is great, but for some more info I did some benchmarking of setting GOMAXPROCs vs not: Pretty substantially better in some cases
Change:
t.Fatalf("%d:, error writing to stdout: %v", i, err) } out.Close() <del> select { case <-clientStdoutReadDone: case <-time.After(10 * time.Millisecond): t.Fatalf("%d: timed out waiting for client to read stdout", i) } </del> <ins> <-clientStdoutReadDone </ins> } else if out != nil { t.Fatalf("%d: stdout: expected nil: %#v", i, out) }

Discussion:
this is you
Hmm, I had upped waiting from 100ms to 500ms and that seemed to fix it. Do you have any better ideas?
Don't wait? :)
If the only reason you would timeout would be the code is broken, that's why the test runs have -timeout set.
Then the test fails immediately. It's waiting for the net.Listen calls to finish so it can connect to the specified local ports.
*finish enough so that socket connections work
So I can remove the timeout gating in my tests?
Yes ----- Original Message -----
Just failed again: https://travis-
Seems to be failing frequently now.
If this is test is failing again, my gut says it's not the same root cause. The original failure was a timeout issue. This new one is connection reset by peer. I've got the test running in a loop waiting for a failure but haven't seen one yet. is this still failing frequently?
No. It had failed twice in ~10 builds when I reopened this issue, but hasn't failed since. Reclosing. Will file a new issue if it recurs.
Change:
return admission.NewForbidden(a, err) } <del> if d.hostPID && pod.Spec.SecurityContext != nil && pod.Spec.SecurityContext.HostPID { return admission.NewForbidden(a, fmt.Errorf("cannot exec into or attach to a container using host pid")) } </del> <ins> if pod.Spec.SecurityContext != nil { securityContext := pod.Spec.SecurityContext if d.hostNetwork && securityContext.HostNetwork { return admission.NewForbidden(a, fmt.Errorf("cannot exec into or attach to a container using host network")) } </ins> <del> if d.hostIPC && pod.Spec.SecurityContext != nil && pod.Spec.SecurityContext.HostIPC { return admission.NewForbidden(a, fmt.Errorf("cannot exec into or attach to a container using host ipc")) </del> <ins> if d.hostPID && securityContext.HostPID { return admission.NewForbidden(a, fmt.Errorf("cannot exec into or attach to a container using host pid")) } if d.hostIPC && securityContext.HostIPC { return admission.NewForbidden(a, fmt.Errorf("cannot exec into or attach to a container using host ipc")) } </ins> } if d.privileged && isPrivileged(pod) {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: currently only are checked in admission controller What you expected to happen: hostNetwork should also be checked to deny exec /attach How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/kind bug /sig auth
cc
Change:
corev1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/meta" <ins> apimachineryvalidation "k8s.io/apimachinery/pkg/api/validation" </ins> "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" "k8s.io/apimachinery/pkg/runtime" ) <del> const totalAnnotationSizeLimitB int64 = 256 * (1 << 10) // 256 kB </del> type lastAppliedUpdater struct { fieldManager Manager }

Discussion:
Expose totalAnnotationSizeLimitB in the validation package: This value is useful for validating annotations outside of the validation package, such as in SSA: Otherwise, size validation on annotations outside of the package would diverge and cause issues later. /kind cleanup /wg api-expression cc
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
Change:
} } <ins> for _, container := range pod.Spec.InitContainers { if container.Resources.Limits.Cpu().IsZero() { cpuLimitsDeclared = false } if container.Resources.Limits.Memory().IsZero() { memoryLimitsDeclared = false } containerHugePageLimits := HugePageLimits(container.Resources.Requests) for k, v := range containerHugePageLimits { if value, exists := hugePageLimits[k]; !exists || v > value { hugePageLimits[k] = v } } } </ins> // quota is not capped when cfs quota is disabled if !enforceCPULimits { cpuQuota = int64(-1)

Discussion:
I noticed ResourceConfigForPod isn't checking here: The methods called by ( and ) do check , but it looks like and can be true for burstable pods even when some of the initContainers do not declare cpu/memory limits. I'm not sure what the implications of setting these values are if an initContainer has no cpu or memory limit: /sig node /assign
After reading the code, I prefer that this is a bug according to . would you confirm? /assign I opened .
/triage accepted
Change:
func init() { utilruntime.Must(logsapi.AddFeatureGates(utilfeature.DefaultMutableFeatureGate)) <ins> // Prevent memory leak from OTel metrics, which we don't use: // https://github.com/open-telemetry/opentelemetry-go-contrib/issues/5190 otel.SetMeterProvider(noop.NewMeterProvider()) </ins> } const (

Discussion:
Since updating from Kubernetes 1.26. to 1.29. we experiences OOM-Kills on control plane nodes. After some investigation we found that adding to the fixed the issue. (Found this via pprof/heap of one apiserver: heap dump could be if needed) Before the update to 1.29.* the control planes were running with 4GB of memory with the same worklow in the cluster without issues. After the workarround using the feature gate the memory consumption of the whole control plane is not at ~2GB. In case there is an issue with other components, memory consumption of the apiserver should not be that excessive. We just had the K8s cluster running and saw a permant increase in memory usage of the control plane nodes. And after some time (can not give a specific duration) the OS of the control plane node started to OOM kill processes. Let us know if you need additional information. <details</detailson-premise; control-planes are running with 4 CPU cores, 8GB of memory and and NVME discs <details</details<details</details<details</detailsNo response
/sig api-machinery
Please provide the pprof, and what is the size of your cluster.
As we were not sure if sharing the pprof is secure, we decided to only share screenshots first: ! ! From this information we found the this which pointed us to the mentioned feature flag. We sometimes see etcd connection timeouts in the apiserver logs, maybe this could be related but should not cause this behaviour. 5 control planes ~100 worker nodes ~1700 Pods
Can you provide the pprof without , so could compare the two?
Sure, the current pprof with set: ! !
cc
I believe this is Sounds like we may need to backport some of the dependency bumps
/assign
/sig instrumentation
/triage accepted (as it's now assigned to
/triage accepted
We need to apply the workaround in It should be simple, but needs to be backported to 1.27
all versions starting 1.27 right ?
Thanks for taking care of this so quickly
yes. All versions starting 1.27.
Actually, this only needs to be backported to v1.29.

At 1.28, we were using v0.35.0 of otelgrpc, which did not include metrics at the time.
Cherry-picks:
Change:
"description": "When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history.", "required": false, "allowMultiple": false <del> }, { "type": "string", "paramType": "path", "name": "namespace", "description": "object name and auth scope, such as for teams and projects", "required": true, "allowMultiple": false </del> } ], "responseMessages": [

Discussion:
The selflink provided in the api response for component statuses (/api/v1/componentstatuses) is broken. For example: /api/v1/namespaces/componentstatuses/controller-manager (as specified in the response of /api/v1/componentstatuses), will return: { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } while: /api/v1/namespaces/default/componentstatuses/controller-manager, will return the data. In addition, and this is asked for better understanding, are the component statuses namespace scoped? as far as I understood etcd, the scheduler and the controller manager were shared across the kubernetes cluster. If they aren't namespace scoped, what is the logic behind specifing a namespace in these api requests (as shown in ): /api/v1/namespaces/{namespace}/componentstatuses /api/v1/namespaces/{namespace}/componentstatuses/{name} If they are in fact namespace scoped, would you be kind and share an explanation/link to a documentation page?
I agree that it doesn't make a lot of sense for this to be namespaced given what's in it at the moment. Given what I'd like it to contain, the namespace might make more sense in the future. The self link is super broken right now, though, probably due to lack of actual namespace. there's probably a bug in the go-restful setup code for this. Can you take a look at some point? Also it might be worth mentioning that this will probably change in the near future, is working on a replacement.
The whole /componentstatus API is just broken. It needs rewriting.
Change:
// Check iptables chain and rules epIpt := netlinktest.ExpectedIptablesChain{ string(kubeServicesChain): { <ins> {JumpChain: string(KubeLoadBalancerChain), MatchSet: kubeLoadBalancerSet}, {JumpChain: string(KubeMarkMasqChain), MatchSet: kubeClusterIPSet}, {JumpChain: string(KubeMarkMasqChain), MatchSet: kubeExternalIPSet}, {JumpChain: "ACCEPT", MatchSet: kubeExternalIPSet}, // With externalTrafficOnlyArgs {JumpChain: "ACCEPT", MatchSet: kubeExternalIPSet}, // With dstLocalOnlyArgs {JumpChain: string(KubeNodePortChain), MatchSet: ""}, </ins> {JumpChain: "ACCEPT", MatchSet: kubeClusterIPSet}, {JumpChain: "ACCEPT", MatchSet: kubeLoadBalancerSet}, <del> {JumpChain: "ACCEPT", MatchSet: kubeExternalIPSet}, </del> }, } checkIptables(t, ipt, epIpt)

Discussion:
<!-- 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 --ipvs mode didn't preserve client IP for NodePort Service with protocol SCTP and ExternalTrafficPolicy Local. iptables mode works fine. ipvs mode with TCP and UDP protocol works fine. Client IP for NodePort Service should be preseved when ExternalTrafficPolicy is Local regardless of the mode and the protocol. kube-proxy mode to ipvs a NodePort service with protocol SCTP and ExternalTrafficPolicy Local the NodePort service, the client IP was not preserved This is caused by wrong order of iptables rules that match kubeNodePortLocalSetSCTP and kubeNodePortSetSCTP: Kubernetes version (use ): v1.22.0 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig network /assign
/triage accepted
Change:
Status: v1.NodeStatus{ Conditions: []v1.NodeCondition{ { <ins> Type:               v1.NodeOutOfDisk, Status:             v1.ConditionFalse, Reason:             "KubeletHasSufficientDisk", Message:            fmt.Sprintf("kubelet has sufficient disk space available"), LastHeartbeatTime:  metav1.Time{}, LastTransitionTime: metav1.Time{}, }, { </ins> Type:               v1.NodeMemoryPressure, Status:             v1.ConditionFalse, Reason:             "KubeletHasSufficientMemory",

Discussion:
Both https://k8s- and https://k8s- started failing recently. Their 1.7 counterparts are passing. The difference between the last passing and the first failing tests is: Probably something in broke the tests. /sig scheduling /cc /kind bug
It looks like there isn't enough cpu on the master to run the cos-nvidia-installer daemonset. Did we add any addons recently?
My previous comment is a red herring. It is an issue with . Ill post a fix soon. From the scheduler logs on the master:
that's a benign error. The daemonset is not expected to run on the master. But there is no easy way to express that request in our APIs.
Yes, the pod not scheduling on the master is benign. The actual error is that we do not report node condition , so it is left as . The fix is to report that is false.
The tests are still failing. /reopen
/assign
I will be updating to track progress.
tests are green again! /close
Change:
set = obj.(*apps.StatefulSet) } if set.Status.Replicas != 3 { <del> t.Error("Falied to scale statefulset to 3 replicas") </del> <ins> t.Errorf("set.Status.Replicas = %v; want 3", set.Status.Replicas) </ins> } }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Unit test error message match the conventional Go style: For example: if got, want := set.Status.Replicas, 3; got != want { t.Errorf("set.Status.Replicas = %v; want %v", got, want) }
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 testing
/assign
/reopen
Change:
set_num_migs if [[ ${KUBE_USE_EXISTING_MASTER:-} == "true" ]]; then <ins> detect-master </ins> parse-master-env create-nodes elif [[ ${KUBE_REPLICATE_EXISTING_MASTER:-} == "true" ]]; then

Discussion:
Create a service , and manually create an Endpoints with an external IP address. Access the service proxy, it fails with 503, "no endpoints available for service ...". I would expect proxy to work (parity with pod-endpoint based Services). Note: 198.18.0.254 is RFC 6890 (reserved for benchmarking). I was using it to test timeout scenarios. With this example, I expect to timeout. Instead, it fails immediately with 503. If I comment out the below validation and compile kube-apiserver, it works as I expect: <details</details<detailsGKE </detailsNo response No response No response No response
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
is ok to be able to use IPs that don't belong to pod so the apiserver can be used as a proxy to external endpoints? There were several CVEs on that area, or may remember better than me
No. Limiting the apiserver proxy to IPs set by an actor with pod status permissions is intentional
Xref
/remove-kind bug /kind documentation this is working as intended, if it is unclear this is as intended, we should improve documentation to make that clear
Agree it is WAI - what's the right place to document this? k/website or is ther an API doc-comment for /proxy/ that feeds into openapi? I don't see any obvious place to document the limitations of that sub-resource
Looks like addressed this but was inadvertently lost near August 2022.
should we remove this too?
Yeah, do you want to do it or shall I? Antonio Ojea
Tim Hockin