jiebi/CodeConvo huggingface dataset:
Change:
} // Returns a PVC definition based on the namespace. <ins> // Note: if this PVC is intended to be pre-bound to a PV, whose name is not //   known until the PV is instantiated, then the func createPVPVC will add //   pvc.Spec.VolumeName to this claim. </ins> func makePersistentVolumeClaim(ns string) *api.PersistentVolumeClaim { // Specs are expected to match this test's PersistentVolume

Discussion:
Context: NodeSwap feature gate was recently . Currently, as per , swap is only supported with cgroup v2 - cgroup v1 is no longer supported. For this reason, we decided to fail kubelet if NodeSwap feature gate is enabled and the node runs with cgroup v1. This would help prevent any surprises for the user by failing as soon as possible. This effort is being implemented in this PR: The problem: Currently, swap jobs are running with cgroup v1. Swap tests were in a way that they first check on which environment they're being run (e.g. which cgroup version? is NodeSwap FG enabled? Which swapBehavior is defined? etc) and then expect the right behavior to take place. With v1, the tests expect the containers to be defined without swap access. While the tests pass, they are much less valuable, since all they check is that swap is disabled for v1 workloads. The tests would be much more valuable if they would run with v2, therefore actually ensure that proper swap limitations are configured. In addition, is dependent on these changes, since as of now the jobs immediately fail with this PR since kubelet fails on an environment with cgroup v1 and swap enabled. What needs to change: [x] CRI-O swap related jobs should be defined to run with cgroup v2 (e.g. ) [x] containerd swap related jobs should be defined to run with cgroup v2 (e.g. ). Future work: In the future, we might consider introducing more jobs to check swap. Ideally, both and would be tested, perhaps by periodic jobs.
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
/sig testing
/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
Change:
APIVersion: "v1", FieldPath:  "spec.containers[3]", }, <del> Reason:  "Stopped", Message: "some verbose message: 1", Source:  v1.EventSource{Component: "eventTest"}, Count:   1, Type:    v1.EventTypeNormal, </del> <ins> Reason:              "Stopped", Message:             "some verbose message: 1", Source:              v1.EventSource{Component: "eventTest"}, ReportingController: "eventTest", Count:               1, Type:                v1.EventTypeNormal, </ins> }, expectLog:    `Event(v1.ObjectReference{Kind:"Pod", Namespace:"baz", Name:"foo", UID:"differentUid", APIVersion:"v1", ResourceVersion:"", FieldPath:"spec.containers[3]"}): type: 'Normal' reason: 'Stopped' some verbose message: 1`, expectUpdate: false,

Discussion:
From the Deprecated API Migration Guide: , since v1.19, the has been using the new reportingController and reportingInstance to replace the decrecated source.component and But when I checked the Kube events in a cluster with version 1.26.0, those new fields are empty and the supposed to be deprecated fields have not been renamed. Seeing the values in the new fields like reportingController and reportingInstance an Kubernetes cluster with version 1.26.0 some Kube events the Kube events details for the field of reportingController, reportingInstance, source.component, No response <detailsServer Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-12-11T00:15:47Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"} </details<detailsAzure </details<details</details<details</details<details</details<details</details
/sig instrumentation
I have also encountered this issue in my local 1.26.0 Kubernetes cluster, which does not align with the deprecation guide described in I believe I can investigate this further
/assign
Thank you for making the PR to fix this! Also a comment in the PR for the doc update.
/triage accepted
Change:
cnt-- // if device is no longer used, see if need to logout the target if cnt == 0 { <del> // strip -lun- from device path ind := strings.LastIndex(device, "-lun-") prefix := device[:(ind - 1)] </del> <ins> device, prefix, err := extractDeviceAndPrefix(mntPath) if err != nil { return err } </ins> refCount, err := getDevicePrefixRefCount(c.mounter, prefix) if err == nil && refCount == 0 { // this portal/iqn are no longer referenced, log out // extract portal and iqn from device path <del> ind1 := strings.LastIndex(device, "-iscsi-") portal := device[(len("/dev/disk/by-path/ip-")):ind1] iqn := device[ind1+len("-iscsi-") : ind] </del> <ins> portal, iqn, err := extractPortalAndIqn(device) if err != nil { return err } </ins> glog.Infof("iscsi: log out target %s iqn %s", portal, iqn) out, err := c.plugin.execCommand("iscsiadm", []string{"-m", "node", "-p", portal, "-T", iqn, "--logout"}) if err != nil {

Discussion:
During iscsi volume cleanup, kubelet reads from and retrieves a list of device paths where iscsi volume mounts on. The device path was expected to be in the form of . But currently the device path in is in the form of , thus iscsi panicked . I suspect this panic started to happen after switched to use from . seems to always resolve device path (see output below), and thus the expected iscsi configuration in the device path no longer exists.
Change:
err:        "", }, { <ins> name:       "allow create of my node pulling name from object", podsGetter: noExistingPods, attributes: admission.NewAttributesRecord(mynodeObj, nil, nodeKind, mynodeObj.Namespace, "", nodeResource, "", admission.Create, mynode), err:        "", }, { </ins> name:       "allow update of my node", podsGetter: existingPods, attributes: admission.NewAttributesRecord(mynodeObj, mynodeObj, nodeKind, mynodeObj.Namespace, mynodeObj.Name, nodeResource, "", admission.Update, mynode),

Discussion:
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 ): Client Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-alpha.4.52+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-05-19T06:57:30Z", GoVersion:"go1.8.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-alpha.4.52+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-05-19T06:57:30Z", GoVersion:"go1.8.1", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know: None
Change:
continue } <del> // Check the node readiness condition (logging all). for i, cond := range node.Status.Conditions { Logf("Node %s condition %d/%d: type: %v, status: %v", name, i+1, len(node.Status.Conditions), cond.Type, cond.Status) // Ensure that the condition type is readiness and the status // matches as desired. if cond.Type == api.NodeReady && (cond.Status == api.ConditionTrue) == wantReady { Logf("Successfully found node %s readiness to be %t", name, wantReady) return true } </del> <ins> if isNodeReadySetAsExpected(node, wantReady) { return true </ins> } } Logf("Node %s didn't reach desired readiness (%t) within %v", name, wantReady, timeout) return false } <ins> // Filters nodes in NodeList in place, removing nodes that do not // satisfy the given condition // TODO: consider merging with pkg/client/cache.NodeLister func filterNodes(nodeList *api.NodeList, fn func(node api.Node) bool) { var l []api.Node for _, node := range nodeList.Items { if fn(node) { l = append(l, node) } } nodeList.Items = l } </ins> // LatencyMetrics stores data about request latency at a given quantile // broken down by verb (e.g. GET, PUT, LIST) and resource (e.g. pods, services). type LatencyMetric struct {

Discussion:
I ran e2e tests against docker 1.7.0-rc2 release, found a bunch of issues. Here is one I think it belongs to kubernetes for sure. 1) ResizeNode test failed, the machine is removed from instance group: But kubectl get nodes still returns 3 ndoes: This might be caused by the new docker binary I am testing against here. This is not the issue I am filing here. 2) Now networking test is running later, I noticed that the test is putting a pod on each node: nettest-gwtc4 on node e2e-test-dawnchen-minion-5l11 I haven't checked networking code in detail yet, not sure the issue is test itself, or scheduler issue. cc/ since you recently changed this. cc/
The networking test doesn't use the scheduler, it manually fills in the host field.
Ok, then we should filter out NotReady nodes from testing; otherwise, the test itself has the dependencies on other tests.
Yes, that test is doing a questionable thing.
Agreed.
I implemented skipping not-ready nodes in . Is it enough to close this issue, or is there something else to be done here?
I think that should fix the issue. ?
status: waiting for merge of
Change:
return nil } } <ins> // If we're past the position of the last describe's rparen, pop the describe off if lastDescribe > -1 && node != nil { if node.Pos() > v.describes[lastDescribe].rparen { v.describes = v.describes[:lastDescribe] } } </ins> return v }

Discussion:
What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
Change:
tags = ["automanaged"], ) <ins> go_test( name = "k8s.io/apiserver/pkg/endpoints/metrics_test", srcs = ["k8s.io/apiserver/pkg/endpoints/metrics/metrics_test.go"], library = ":k8s.io/apiserver/pkg/endpoints/metrics", tags = ["automanaged"], ) </ins> filegroup( name = "package-srcs", srcs = glob(["**"]),

Discussion:
Some of the exported prometheus metrics, e.g. include high-cardinality fields like the User-Agent. This creats a large number of time-series on the prometheus server is ususally not advised to do. Please consider reducing the cardinality of the exported metrics.
Change:
skipPlugins.Insert(pl.Name()) continue } <del> metrics.PluginEvaluationTotal.WithLabelValues(pl.Name(), metrics.PreFilter, f.profileName).Inc() </del> if !s.IsSuccess() { s.SetFailedPlugin(pl.Name()) if s.IsUnschedulable() {

Discussion:
We observed degradation in scheduling throughput, putting it under 100 pods/s. Respective pprof of kube-scheduler points it to ! /sig scheduling /kind regression 100 pods/node n/a No response <details</details<details</details<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
/cc
/sig scalability
Thanks for noticing it /assign
just to confirm this bug is present only in 1.27 ( introduced with pluginevaluationtotal metric) , isn't it ?
Exactly, 1.27+ (so the current master as well) to be specific.
Change:
framework.ExpectNoError(err, "3 pods not found") // delete Collection of pods with a label in the current namespace <del> err = f.ClientSet.CoreV1().Pods(f.Namespace.Name).DeleteCollection(context.TODO(), metav1.DeleteOptions{}, metav1.ListOptions{ </del> <ins> err = f.ClientSet.CoreV1().Pods(f.Namespace.Name).DeleteCollection(context.TODO(), metav1.DeleteOptions{GracePeriodSeconds: &zero}, metav1.ListOptions{ </ins> LabelSelector: "type=Testing"}) framework.ExpectNoError(err, "failed to delete collection of pods")

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-e2e-gce (5% of runs) pull-kubernetes-e2e-kind-ipv6 pull-kubernetes-e2e-gce-ubuntu-containerd Which test(s) are flaking: This is the flakiest test in the e2e job according to Testgrid link: Reason for failure: Anything else we need to know:
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
merged 2 weeks ago in
/assign
potential mitigation in
To track down the test flaking there was some great feedback in by and was created as a potential fix based on that feedback /cc
Change:
return pdbs[0] } <ins> // This function returns pods using the PodDisruptionBudget object. // IMPORTANT NOTE : the returned pods should NOT be modified. </ins> func (dc *DisruptionController) getPodsForPdb(pdb *policy.PodDisruptionBudget) ([]*v1.Pod, error) { sel, err := metav1.LabelSelectorAsSelector(pdb.Spec.Selector) if sel.Empty() {

Discussion:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No. What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): DisruptionController getPodsForPdb Is this a BUG REPORT or FEATURE REQUEST? FEATURE REQUEST in we have function return pods using . but at the end we perform a copy of the pod array that we listed with : this is not necessary cc
/assign
/kind enhancement
Change:
if sp.TargetPort.Type == intstr.Type(intstr.Int) { w.Write(LEVEL_0, "TargetPort:t%d/%sn", sp.TargetPort.IntVal, sp.Protocol) } else { <del> w.Write(LEVEL_0, "TargetPort:t%d/%sn", sp.TargetPort.StrVal, sp.Protocol) </del> <ins> w.Write(LEVEL_0, "TargetPort:t%s/%sn", sp.TargetPort.StrVal, sp.Protocol) </ins> } if sp.NodePort != 0 { w.Write(LEVEL_0, "NodePort:t%st%d/%sn", name, sp.NodePort, sp.Protocol)

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?: What happened: when using , the TargetPort is wrong What you expected to happen: if the targetPort is string, show the name correctly. Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
could you paste more details about the Kubernetes Version and the yaml you used to create the service? I tried to reproduce this error but it worked fine in my environment.
use the master branch. yaml output
I'm not sure if the targetPort could be set to string type, looks like the targetPort here makes no sense of port1 for it doesn't point to an actual port. I think we have to validate this value rather than displaying the string. WDYT?
It can be a string, you can see this
thanks for your ref, I will try to fix this and pls let me know if any new progress :)
I have commit a pr
ok, thanks~
Change:
if check_cm_response == 0: # There is an existing ConfigMap, patch it <del> patch = '{"data":{"max-body-size":"1024m"}}' </del> <ins> patch = '{"data":{"body-size":"1024m"}}' </ins> patch_cm_command = kubectl + ['patch', 'cm', cm_name, '-p', patch] patch_cm_response = call(patch_cm_command)

Discussion:
<!-- 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 What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): nginx-load-balancer-conf Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): ` Environment: Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): Ubuntu 16.04.2 LTS Kernel (e.g. ): 4.4.0-71-generic -Ubuntu SMP Fri Mar 24 12:59:01 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: juju Others: What happened: I used the "registry" action to create docker registry inside the cluster. It modified nginx-load-balancer-conf config map. It replaced: body-size: 1024m with (incorrect): max-body-size: 1024m What you expected to happen: Expected ConfigMap to stay as it was How to reproduce it (as minimally and precisely as possible): Deploy cluster with juju and then use "registry" action to create docker registry Anything else we need to know:
Change:
return } if shouldHide(&version, selfVersion) { <del> klog.Warningf("This metric(%s) has been deprecated for more than one release, hiding.", d.fqName) </del> <ins> // TODO(RainbowMango): Remove this log temporarily. https://github.com/kubernetes/kubernetes/issues/85369 // klog.Warningf("This metric(%s) has been deprecated for more than one release, hiding.", d.fqName) </ins> d.isHidden = true } })

Discussion:
cc who found it. the reason is the calls from the import here: i suspect the problem surfaced with this bug fix. cc more refs: is an anti-pattern in this case. ideally metrics registration should not trigger warnings for a simple version output. mitigation on the user side is to pipe stderr to a null device (as long as klog is writing to stderr) /kind bug /priority important-longterm /area kubelet /wg component-standard
/sig node
should be fixed before 1.17.0, doesn't block beta.2
cc
Could this be caused by the following in init() of ? It was marked I wonder when deprecatedRequestLatency can be dropped.
looks like was deprecated in 1.14 - Is that the only one that needs to be dropped? are there more.
Dropping restclientrequestlatencyseconds should remove the warning for --version. In the 1.14 changelog, there were quite a few other metrics deprecated. I guess we don't have to drop them now.
/assign It's an interesting issue. I will investigate it and get back to you. By the way: I tried this morning, I got 4 warnings, things getting worse as we deprecated more metrics this weekend. (the log can not point the exact name of a metric, we intended to improve it in v1.18)
it's being invoked from here: the message is not helpful, since it doesn't tell you which metric is deprecated
Yes. It's a known issue and we intended to improve it in v1.18. Now, I suggest removing the log temporarily, Fired a PR , for reasons as follows: Too many binaries have been affected.(kubelet, kube-proxy, kube-apiserver, kube-controller-manager, kube-proxy, kube-scheduler). We should consider more about this issue. v1.17.0 is fast approaching, we should make a quick fix. All components try to register a deprecated metrics will be affected. Maybe we should record deprecated/hidden metrics by a new metric instead of the log.
Summary the root cause here: According to metrics deprecated policy, if a metric's - = 1, it will become a hidden metric. Hidden means we will not register it to the Prometheus registry by default.

If we try to register a hidden metric to the stability framework, the warning log will be printed out. Because some metrics registered by init() calls from the import, so...
I have tried to print the metric's name at local: kubelet: kube-proxy: kube-apiserver: kube-controller-manager: kube-scheduler:
ideally the registration should happen outside of init(), which means calling it on demand. but i will defer to the owning sigs.
In principle, yes, I agree. Otherwise, we need to be very very careful with every log in the stability framework. I think we can track it and work out by iteration. cc for comments.
Change:
if az.serviceOwnsRule(service, *existingRule.Name) { keepRule := false klog.V(10).Infof("reconcileLoadBalancer for service (%s)(%t): lb rule(%s) - considering evicting", serviceName, wantLb, *existingRule.Name) <del> if findRule(expectedRules, existingRule) { </del> <ins> if findRule(expectedRules, existingRule, wantLb) { </ins> klog.V(10).Infof("reconcileLoadBalancer for service (%s)(%t): lb rule(%s) - keeping", serviceName, wantLb, *existingRule.Name) keepRule = true }

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 --What happened: When the Idle Timeout annotation was set to "3" which isn't a supported case, kube-controller-manager is stuck in deleting Azure LB. New service with the same name couldn't be created again even without the annotation. What you expected to happen: New service should be created successfully. 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: ): Kernel (e.g. ): Install tools: Others: /sig azure /kind bug
/assign Since I'm seeing this on some of our clusters
/priority important-soon
Thanks
- The problem here seems that when we want to call (when processing a delete event) it reconciles the loadbalancer which in turn tries to get the idleTimeout, resulting in an error. one of the strategies is to still construct our diff in case of a delete and exercise the code path at the end. This basically translate into ignoring the error when getting idleTimeout and excluding it from finding if the rule is dirty or not when we are . toughts ? Generally speaking, whenever we update a loadbalancer with unsupported values on annotations, ensuring load balancer will fail resulting in an un-cleaned LB, this is a cross-provider issue. /sig cloud-provider cc
cc
lgtm. the delete operation should continue to do cleanup job even some wrong options are provided from users.