jiebi/CodeConvo huggingface dataset:
Code change:
}, }, ) <ins> s.endpointWorkerMap = make(map[string]bool) s.serviceWorkerMap = make(map[string]bool) s.endpointWorkerDoneChan = make(chan string, maxNoOfClusters) s.serviceWorkerDoneChan = make(chan string, maxNoOfClusters) </ins> return s }

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: GCP OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others: What happened: Memory usage of federation-control-manager keeps on increasing to very large size overtime. What you expected to happen: Memory usage is stable How to reproduce it (as minimally and precisely as possible): Register one or more cluster to federation control plane and watch the top output for the federation-control-manager Also can check the pprof, here is the one such output after federation-control-manager is run for an hour. We can see there are around goroutines created in an hour which are leaked and would consume memory. Anything else do we need to know: I do have a fix for the issue and would be happy to submit it, if this issue is accepted.
plz check the issue
feel free to just submit a pull request, we don't really have a concept of an issue being "accepted" :)
This looks like a legitimate bug. could you please clarify what version of the federated service controller you are running? The image path and version of the container, or a git hash of the source should be sufficient.
i am taking the latest code from master branch.
Code change:
} func (stats *seatDemandStats) update(obs fq.IntegratorResults) { <ins> stats.highWatermark = obs.Max if obs.Duration <= 0 { return } if math.IsNaN(obs.Deviation) { obs.Deviation = 0 } </ins> stats.avg = obs.Average stats.stdDev = obs.Deviation <del> stats.highWatermark = obs.Max </del> envelope := obs.Average + obs.Deviation stats.smoothed = math.Max(envelope, seatDemandSmoothingCoefficient*stats.smoothed+(1-seatDemandSmoothingCoefficient)*envelope) }

Related discussion:
text: hi, we have 3 master nodes , one of nodes errors output this err kubectl -n kube-system logs kube-apiserver-loshu-k8s-master02 k8s version lb proxy haproxy+keeaplive on-premise ubuntu 22.04 kubeadm containerd calico
/sig api-machinery for triage
/cc
Yes, looks like a real bug, an oversight in logic. Will fix.
Will this fix be backported to v1.26?
/cc hello, I want to know what the scenario of this problem is, what if I reproduce it? thanks
I have k8s 1.26 and recently got same error.
/triage accepted
I have observed the same error on v1.27.6
I have observed the same error on v1.28.3
I have observed the same error on v1.28.4
Try to update to the latest patch version.
it seems fixed in See vs
yep, it's been restored, but I want to know the reason it happens
Code change:
require ( github.com/blang/semver v3.5.0+incompatible <ins> github.com/go-logr/logr v0.1.0 </ins> github.com/google/go-cmp v0.4.0 github.com/konsorten/go-windows-terminal-sequences v1.0.2 // indirect github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369 // indirect

Related discussion:
text: What would you like to be : As part of should add logging configuration allowing to change logging implementation. Things to implement: --logging-format - flag to pick between available implementations. Defaults to "text" using unchanged klog. LoggingConfig - structure storing component configuration for logging LogFormatRegistry - Used for registration of additional log formats. New formats should be registered by providing unique name and implementation of interface LoggingConfig.Complete method should configure klog by passing logr interface implementation into klog.SetLogger method Why is this needed: Subtask of /help /wg component-standard
The klog 1.0.0 version looks like no SetLogger method, should update klog version in vendor?
yes, forgot about that. I remember saying that it will require some changes, but shouldn't be to hard. I will help with it if needed.
/assign /remove-help
Klog was upgraded to v2.
Code change:
"[Flaky]", }, { <del> "a disruptive test case that is invalid [Disruptive]", "[Disruptive]", }, { </del> "a feature test case that is invalid [Feature:Awesome]", "[Feature:Awesome]", },

Related discussion:
text: What would you like to be : Our tooling that makes the list of conformance tests needs to allow conformance tests to be marked as disruptive. Why is this needed: To test default, conformance behavior which may be disruptive (e.g. taint eviction) ref /sig testing /area conformance
Code change:
"[Flaky]", }, { <del> "a disruptive test case that is invalid [Disruptive]", "[Disruptive]", }, { </del> "a feature test case that is invalid [Feature:Awesome]", "[Feature:Awesome]", },

Related discussion:
text: What happened: Ran a conformance test run (using Sonobuoy) on One of the taint based tests a NoExecute taint to a node which evicted all workloads including the Sonobuoy workload itself. If this had been a prod workload, numerous prod workloads could have been impacted. What you expected to happen: Test run as normal with reasonable results. Able to run conformance tests with minimal impact on a running cluster. How to reproduce it (as minimally and precisely as possible): on a v1.16.0 cluster. Anything else we need to know?: Environment: Kubernetes version (use ): /area conformance
/sig testing /sig architecture /sig scheduling
Summarizing the many conversations on the PR and in Slack regarding this: We wish we had identified the lack of a tag sooner and could have taken better action. Since the release is 2 days away and our own tooling currently prohibits us from marking tests as both and , we've decided to let the release proceed with this "bug". Risk: Someone running the conformance tests may unexpectedly have their workloads evicted Mitigation: Sonobuoy v0.16.0 will provide the capabilities to the user to run a "conformance-lite" (name TBD) run if they'd like to run the conformance tests against a cluster with prod workloads. This way end-users can still be reasonably sure of their cluster's continued well-being. This mode will manually skip the tests in question until they can be more appropriately marked as Sonobuoy will also provide, consistent with past behavior, the means to run the full conformance suite including these disruptive tests. Eventual solution: Sonobuoy will, most likely, need to continue offering a "non-disruptive-conformance" mode to aid in end user testing but the regexp will change and should be able to just skip tests K8s tooling needs to be tweaked to allow for tests to be marked as The tag should be to these tests.
Code change:
if err != nil { t.Fatal(err) } <del> if res.StatusCode != http.StatusGatewayTimeout { t.Errorf("got res.StatusCde %d; expected %d", res.StatusCode, http.StatusServiceUnavailable) </del> <ins> if actual, expected := res.StatusCode, http.StatusGatewayTimeout; actual != expected { t.Errorf("got status code %d; expected %d", actual, expected) </ins> } res.Body.Close() }

Related discussion:
text: Similar to and easily reproducible. The handler occasionally completes and sends a response before timing out. /kind failing-test /kind flake /sig api-machinery
/assign
/assign Thank you very much for fixing these tests.
/triage accepted
Code change:
http_archive( name = "io_kubernetes_build", <del> sha256 = "66a44fd5f6357268340d66fbd8a502065445a7c022732fe5f6fd84d9a20f75a3", strip_prefix = "repo-infra-e8f2f7c3decf03e1fde9f30d249e39b8328aa8b0", urls = mirror("https://github.com/kubernetes/repo-infra/archive/e8f2f7c3decf03e1fde9f30d249e39b8328aa8b0.tar.gz"), </del> <ins> sha256 = "21160531ea8a9a4001610223ad815622bf60671d308988c7057168a495a7e2e8", strip_prefix = "repo-infra-b4bc4f1552c7fc1d4654753ca9b0e5e13883429f", urls = mirror("https://github.com/kubernetes/repo-infra/archive/b4bc4f1552c7fc1d4654753ca9b0e5e13883429f.tar.gz"), </ins> ) http_archive(

Related discussion:
text: /kind bug What happened: If you start with a minimal Debian image and attempt to install kubernetes- as an artifact from a Bazel build, it will fail with: This has been a known issue in the past, and there are workarounds for CI in place, but it's still unexpected behaviour () What you expected to happen: kubernetes- installs. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: n/a OS (e.g. from /etc/os-release): debian Kernel (e.g. ): n/a Install tools: Others: /sig cluster-lifecycle
hm, this might be a bug in our "fast" tar builder (). if I revert to the bazel-supplied version: then the tarball looks more like we'd expect:
I'll dig a bit more. I started with the assumption that this was a Bazel bug needing a workaround.
cc
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 /assign This should probably still be fixed.
/assign
/lifecycle active
Once is ok & merged, referenced will need updating in
Oops. Didn't realise this issue was getting spammed by my bazel testing.
yep, better not include references in commits. is this resolved?
Yes, fixed this.
we still need to bump the kubernetes/repo-infra dependency in WORKSPACE though. I'll open a PR to do that for kubernetes/kubernetes.
Code change:
return bo1.Before(bo2) } <ins> // NumUnschedulablePods returns the number of unschedulable pods exist in the SchedulingQueue. func (p *PriorityQueue) NumUnschedulablePods() int { p.lock.RLock() defer p.lock.RUnlock() return len(p.unschedulableQ.pods) } </ins> // UnschedulablePodsMap holds pods that cannot be scheduled. This data structure // is used to implement unschedulableQ. type UnschedulablePodsMap struct {

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Today, the scheduler re-processes unschedulable nodes . Node updates are sent by Kubelet frequently (every 10 seconds) and often times they don't change any of the node properties that could potentially make them feasible. We should be smarter about these updates and move pods to the schedulable queue only when certain properties of nodes change that could make them feasible. These properties include node allocatable, node conditions, taints, labels, .... Why is this needed: Improves performance of the scheduler and avoids doing unnecessary attempts to schedule pods. This is particularly helpful when a cluster has a lot of unschedulable pods. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature This is not a feature really. It is performance optimization, but in the absence of such a label, I need to use "feature" here. /sig scheduling
I can help to fix it. /assign mlmhl
The main reason for this problem is / update their status too frequently and most of these updates are heartbeats without any meaningful change. Recently sig-node introduces a new to alleviate this problem. With this mechanism, kubelet will split heartbeat and node status updates into two independent operations, and reduce the frequency of status updates to once per 1 minute(or more). In the long run this mechanism can indeed alleviate our problems, but at present it does not help us much as this is still an alpha feature and the node status updates frequency is still a bit high(per 1 minute right now).
Maybe we can try comparing old and new nodes after stripping their heartbeat info, like this:
I think that had sent earlier is more efficient. However, that PR does not filter out . In Wei's code, the heartbeat time is removed correctly. I think we should fix this issue and resubmit that PR.
could you resubmit a PR to: disregard in conditions comparison: and (optionally) disregard timestamp in taints comparison:
Thanks for all your advice, a new PR is submitted: This PR does not include your second suggestion(disregard timestamp in taints comparison) as I'm not sure if can be changed when node updating.
Code change:
return bo1.Before(bo2) } <ins> // NumUnschedulablePods returns the number of unschedulable pods exist in the SchedulingQueue. func (p *PriorityQueue) NumUnschedulablePods() int { p.lock.RLock() defer p.lock.RUnlock() return len(p.unschedulableQ.pods) } </ins> // UnschedulablePodsMap holds pods that cannot be scheduled. This data structure // is used to implement unschedulableQ. type UnschedulablePodsMap struct {

Related discussion:
text: If it can be changed, I will add this filter later, otherwise I think we can keep the current implementation to make the compare operation simpler and faster. What's more, just as I said in the PR's description, I'm not sure how much side effects this change has on scheduler's resource consumption, as it always copy node's conditions before comparison.
I am thinking whether we could move this logic(whether node became more schedulable) to kubelet, kubelet reports it through heartbeats.
Code change:
return nil, fmt.Errorf("container not found (%s)", o.ContainerName) } <del> if len(o.SuggestedCmdUsage) > 0 { </del> <ins> if o.EnableSuggestedCmdUsage { </ins> fmt.Fprintf(o.ErrOut, "Defaulting container name to %s.n", pod.Spec.Containers[0].Name) <del> fmt.Fprintf(o.ErrOut, "%sn", o.SuggestedCmdUsage) </del> <ins> fmt.Fprintf(o.ErrOut, "Use '%s describe pod/%s -n %s' to see all of the containers in this pod.n", o.ParentCommandName, o.PodName, o.Namespace) </ins> } klog.V(4).Infof("defaulting container name to %s", pod.Spec.Containers[0].Name)

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: The pod name is missing in suggested cmd usage when executing : What you expected to happen: The suggested cmd usage should be a complete cmd like the one got from How to reproduce it (as minimally and precisely as possible): Use to attach any pod/deployment/service, the PodName will be missing in the suggested cmd usage like above. Anything else we need to know?: It works fine for kubectl < v1.12 Environment: Kubernetes version (use ): v1.13.1 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 cli /assign
Code change:
<ins> /* Copyright 2021 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package options import ( "net" "testing" "k8s.io/apiserver/pkg/server" "k8s.io/client-go/rest" ) func TestEmptyMainCert(t *testing.T) { secureServingInfo := &server.SecureServingInfo{} var loopbackClientConfig *rest.Config s := (&SecureServingOptions{ BindAddress: net.ParseIP("127.0.0.1"), }).WithLoopback() ln, err := net.Listen("tcp", "127.0.0.1:0") if err != nil { t.Fatalf("failed to listen on 127.0.0.1:0") } defer ln.Close() s.Listener = ln s.BindPort = ln.Addr().(*net.TCPAddr).Port if err := s.ApplyTo(&secureServingInfo, &loopbackClientConfig); err != nil { t.Errorf("unexpected error: %v", err) } if loopbackClientConfig == nil { t.Errorf("unexpected empty loopbackClientConfig") } if e, a := 1, len(secureServingInfo.SNICerts); e != a { t.Errorf("expected %d SNICert, got %d", e, a) } } </ins>

Related discussion:
text: The code block does these actions: the self-signed cert for loopback connection the loopbackClientConfig the self-signed cert to the If the main cert () is empty, the loopbackClientConfig will not be created due to this check, loopbackClientConfig shouldn't be left empty, because we have created the SNICert, it's just that we haven't executed action 3 to add the SNICert to the list. Switching the order of action 2 and action 3 will make the loopbackClientConfig successfully created. /kind bug /sig auth api-machinery
Code change:
func (e *transformTest) getEncryptionOptions() []string { if e.transformerConfig != "" { <del> return []string{"--experimental-encryption-provider-config", path.Join(e.configDir, encryptionConfigFileName)} </del> <ins> return []string{"--encryption-provider-config", path.Join(e.configDir, encryptionConfigFileName)} </ins> } return nil

Related discussion:
text: Ref Ref ref /sig auth /kind feature /milestone v1.11 /priority important-longterm /status approved-for-milestone cc
What's need to be done here? I can think only about renaming to and updating the docs. What else?
What's required to promote encryption at rest with static configs to beta?
an example of promoting flags is here: If there's a feature gate, we're going to want to enable it by default too.
/assign
submitted PRs for that: and
[MILESTONENOTIFIER] Milestone Removed From Issue Important: Code freeze is in effect and only issues with may remain in the v1.11 milestone. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Will this make it to Beta in 1.12? From sig-auth on 7/11, it sounded like this was missing a release shepherd. Is anyone owning pushing this forward?
I'll do my best to push this. edit: I did not realize that 1.12 feature freeze is today (or so I heard), I don't think I'll be able to make it :slightlyfrowningface:
Ack - that's what I was wondering (with the feature freeze). Thanks
- Is this making it to the 1.12 ?
The current plan is 1.13
Code change:
if terminated { p.PodSandboxStatus.State = runtimeapi.PodSandboxState_SANDBOX_NOTREADY } <del> p.PodSandboxStatus.Id = string(uuid.NewUUID()) </del> <ins> p.PodSandboxStatus.Id = strings.ReplaceAll(string(uuid.NewUUID()), "-", "") </ins> return p }

Related discussion:
text: Since upgrading from Kubernetes to we no longer get memory metrics from the endpoint on . Example: In our previous version, we would get a response like the following that included utilisation metrics: Hit the endpoint of on a cluster running version . Kubernetes version (use ): Cloud provider or hardware configuration: Provisioned on AWS with OS (e.g: ): Flatcar Container Linux by Kinvolk 2765.2.6 (Oklo) Kernel (e.g. ): 5.10.43-flatcar
/sig node
Hi AlexLastwhich container runtimes are you using? containerd?
Hi AlexLast, I have test on v1.22 with containerd, I did not reproduce this issue. If memory limit is set in the container spec of the pod, /stats/summary will report availableBytes, if memory limit is not set, /stats/summary will not be reported. just like this: ! ! code is here:
/cc We have reports of missing memory metrics on 1.20.8 and 1.21.2 now... was there a cadvisor or similar change that happened?
also /cc as an FYI
If you are using cri-o, it looks like a similar issue to and (possibly an issue with cadvisor/the way cri-o integrates with cadvisor). This would also apply to the dockershim
I'm not able to repro on GKE v1.20.8-gke.700 on containerd
Can you please provide more info about your environment, container runtime etc and possible repro steps? Thanks!
/triage needs-information
Hi, First of all, I am sorry to cut in on you. I have the same issue with Kubelet, in my case with Kubeadm. Here you are the issue: Here you are my installation: Thanks in advance
^ quick summary of the above, appears to be single-node ubuntu (not sure what kernel?) containerd 1.4.6 k8s 1.21.2 kubeadm installer
It is one node. It is only for making easier where is the problem .
Code change:
if terminated { p.PodSandboxStatus.State = runtimeapi.PodSandboxState_SANDBOX_NOTREADY } <del> p.PodSandboxStatus.Id = string(uuid.NewUUID()) </del> <ins> p.PodSandboxStatus.Id = strings.ReplaceAll(string(uuid.NewUUID()), "-", "") </ins> return p }

Related discussion:
text: Kubernetes version: 1.21.2 Cloud provider or hardware configuration: Bare metal (VMware) OS: Ubuntu 18.04.5 LTS Kernel: 4.15.0-147-generic Install tools: Kubeadm Network plugin and version (if this is a network-related bug): Weave 2.8.1 CRI: Containerd 1.4.6
Sure, we're setting the following flags for : Version: We deploy our clusters using , these missing metrics are for all pods in the cluster, including pods with memory requests and limits set.
Hitting the same issue on such kind of environments Then I tested and found no issue on environment
Besides memory metrics, we noticed a loss of network in pods. I commented at the block of container and the block of pod The loss of pods occurs at the same time as loss of pods
I created cluster as follows on 1.21.2 with kubetest containerd 1.4.6 on ubuntu. This is on older version of ubuntu 18.04 LTS on kernel I don't see memory metrics being lost here.
Can we have more details on exact kernel/OS image being used here? I can't seem to repro this on 1.21.2 with same containerd/ ubuntu version as mentioned in
Hi, may I know your output of network metrics in pods?
Hi, I have tested with two kernel versions: P.S: I have just updated my in order to make easier the test. You can use it (it is necessary to install and ). Thanks in advance
We tested with two kernel versions too.
I was able to repro finally -- it looks like missing key here is that you must be using the systemd cgroup driver. With this patch and starting cluster as follows:
Hi do you mean that if using systemd cgroup driver, this issue would happen. In my environment, both containerd and kubelet are using cgroupfs driver, but the issue still exists containerd config dump
Hi, Here you are my Containerd & Kubelet config: ` As far as I know, systemd cgroup driver should be configured in order to have a proper perfomance in Kubernetes. Is it a bug with Kubelet?