jiebi/CodeConvo huggingface dataset:
Change:
<ins> //go:build !windows // +build !windows /* Copyright 2024 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 logs import ( "os" ) func openFileShareDelete(path string) (*os.File, error) { // Noop. Only relevant for Windows. return os.Open(path) } </ins>

Discussion:
The test is failing on Windows [0]: The idea of the test is to check that kubelet still follows and reads the Container Logs after a Log Rotation occured. However, because the followed file is open, it cannot be renamed, and thus, the container logs cannot be rotated. This issue could be prevented if the file would be opened with the [0] [1] Kubelet should not block container log rotation. Run the test ` is failing on Windows. /sig windows /kind bug /kind failing-test latest, master. This unit test has been failing for a while. N/A Windows nodes </detailsN/A N/A N/A
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
/kind failing-test /sig windows
Change:
// The order is based on the restrictiveness & complexity of predicates. // Design doc: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/predicates-ordering.md var ( <del> predicatesOrdering = []string{CheckNodeConditionPred, </del> <ins> predicatesOrdering = []string{CheckNodeConditionPred, CheckNodeUnschedulablePred, </ins> GeneralPred, HostNamePred, PodFitsHostPortsPred, MatchNodeSelectorPred, PodFitsResourcesPred, NoDiskConflictPred, PodToleratesNodeTaintsPred, PodToleratesNodeNoExecuteTaintsPred, CheckNodeLabelPresencePred,

Discussion:
DaemonSet should not respect node's field. It's because cluster operators often want system components to be running and ready before workloads run on a given node. OTOH, DaemonSet does respect NoSchedule taints. This behavior is broken by , because DaemonSet share some predicates code with default scheduler.
/assign
Added this to 1.10 milestone, because it's a regression introduced in 1.10.
can you (or a SIG lead) add status/approved-for-milestone please? I'll add the priority. /priority important-soon
how is this use case satisfied by the daemonset controller creating pods and depending on the scheduler to assign them to nodes? having the scheduler ignore the unschedulable field seems nonsensical
I'd like get this as limitation for alpha feature; when upgrade to beta, I'd like to use taint to replace un-scheduable, so DaemonSet pod can tolerate it on-demand.
Escalating to critical-urgent, since we are now in Code Freeze. Please update daily with status, thanks! /priority critical-urgent /remove-priority important-soon
In short term, scheduler can check of pods and ignore bit of nodes for DS pods. Long term, when TaintNodesByCondition is stable, we should replace bit by taint and have DS controller add toleration for the taint when creating pods.
That doesn't seem proper. Making pods behave differently depending on the type of their creating object is very counterintuitive. That seems more reasonable. I'm less certain about auto- tolerations
- indeed there's some work currently to move from to a taint based behaviour, tracked by
Change:
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.53.0 go.opentelemetry.io/otel v1.28.0 go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.27.0 <ins> go.opentelemetry.io/otel/metric v1.28.0 </ins> go.opentelemetry.io/otel/sdk v1.28.0 go.opentelemetry.io/otel/trace v1.28.0 go.uber.org/zap v1.26.0

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:
switch { case t.ExitCode == 1: // expected <del> case t.ExitCode == 128 && reBug88766.MatchString(t.Message): </del> <ins> case t.ExitCode == 128 && t.Reason == "ContainerCannotRun" && reBug88766.MatchString(t.Message): </ins> // pod volume teardown races with container start in CRI, which reports a failure framework.Logf("pod %s on node %s failed with the symptoms of https://github.com/kubernetes/kubernetes/issues/88766") default:

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 Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: Triage board shows flakes here spiked dramatically on 3/4 /sig node /priority critical-urgent /milestone v1.18
are you able to assist if this is related to recent topology work?
sure, I'll take a look
is this the test you just in ?
As mentioned above, this is a new test that was just , and the test sometimes fails. I don't see that any of the recent topology manager changes would cause these failures. I'll be happy to help out and dig more if or others think otherwise.
This is me, the bugs are untriaged containerd / Kubelet failures with low occurrence rates that this test now exposes. Investigating.
still flaking in non-dockershim environments: pod pod-submit-status-0-14 on node kind-worker2 container unexpected exit code 128: start=1970-01-01 00:00:00 +0000 UTC end=2020-03-06 16:16:54 +0000 UTC reason=StartError message=failed to create containerd task: OCI runtime create failed: starting container process caused " container init caused " mounting "/var/lib/kubelet/pods/-819e-4840-8369-" to rootfs "" at "" caused "stat /var/lib/kubelet/pods/-819e-4840-8369- no such file or directory""": unknown `
Different reason this time. Will continue to enumerate failure modes.
Change:
"type": "array", "items": { "$ref": "#/definitions/io.k8s.apimachinery.pkg.apis.meta.v1.Initializer" <del> } </del> <ins> }, "x-kubernetes-patch-merge-key": "name", "x-kubernetes-patch-strategy": "merge" </ins> }, "result": { "description": "If result is set with the Failure field, the object will be persisted to storage and then deleted, ensuring that other clients can observe the deletion.",

Discussion:
There are two issues: doesn't have merge key The validation code regards it as an error if both Initializers.Result and Initializers.Pending are nil. So if multiple initializer controllers sending patches removing themselves from Initializers.Pending at the same time, the last patch that gets applied will get a validation error.
/sig api-machinery
Change:
promoterE2eRegistry     = registry.PromoterE2eRegistry buildImageRegistry      = registry.BuildImageRegistry gcAuthenticatedRegistry = registry.GcAuthenticatedRegistry <ins> gcEtcdRegistry          = registry.GcRegistry </ins> gcRegistry              = registry.GcRegistry sigStorageRegistry      = registry.SigStorageRegistry gcrReleaseRegistry      = registry.GcrReleaseRegistry

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: 02/19 20:21 PST Testgrid link: Reason for failure: Image pull failure Anything else we need to know:
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 windows cc
Change:
// APILifecycleDeprecated is an autogenerated function, returning the release in which the API struct was or will be deprecated as int versions of major and minor for comparison. // It is controlled by "k8s:prerelease-lifecycle-gen:deprecated" tags in types.go or  "k8s:prerelease-lifecycle-gen:introduced" plus three minor. func (in *CustomResourceDefinition) APILifecycleDeprecated() (major, minor int) { <del> return 1, 19 </del> <ins> return 1, 16 </ins> } // APILifecycleReplacement is an autogenerated function, returning the group, version, and kind that should be used instead of this deprecated type.

Discussion:
The following code snippet is very confusing: Is v1beta1 deprecated in 1.16 or 1.19? Is it to be removed in 1.19 or 1.22? Please clarify the exact versions so the many users of CRD v1beta1 APIs know what to do.
/sig api-machinery
/kind deprecation
/unkind feature
Deprecated in 1.16. Planned to be removed in 1.22. We'll update the docs to be consistent before 1.19 is released.
/assign
Change:
t.Errorf("Expected %v, but got %v", e, a) } <ins> // Test a name + port number (service port 9393 -> target port "p" -> endpoint port 93, using second ip) location, _, err = redirector.ResourceLocation(ctx, "foo-second-ip:9393") if err != nil { t.Errorf("Unexpected error: %v", err) } if location == nil { t.Errorf("Unexpected nil: %v", location) } if e, a := "//[2001:db7::]:93", location.String(); e != a { t.Errorf("Expected %v, but got %v", e, a) } </ins> // Test a scheme + name + port. location, _, err = redirector.ResourceLocation(ctx, "https:foo:p") if err != nil {

Discussion:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery
Change:
} } <ins> func TestCreateFirewallFails(t *testing.T) { name := "loadbalancer" region := "us-central1" desc := "description" gce := &GCECloud{} if err := gce.createFirewall(name, region, desc, nil, nil, nil); err == nil { t.Errorf("error expected when creating firewall without any tags found") } } </ins> func TestRestrictTargetPool(t *testing.T) { const maxInstances = 5 tests := []struct {

Discussion:
In some custom setup cases the prefix-matching logic for GCE load-balancers can break and end up creating a firewall rule with no tags. We should instead refuse to create the rule. In fact, if we find it, we should probably delete the rule, but that's maybe too aggressive. Looking at the logic, if we return error in the tag-selection, we'll abort the whole load-balancer creation, which is unfortunate, but not TERRIBLE. We could just silently not create the firewall but not return error, which will just retry over and over.
/cc
Are you active on this? may have some starter-project bandwidth to help.
Not active. It would indeed be a good starter project :)
Change:
kubeClientConfig.QPS = 99999 kubeClientConfig.Burst = 9999 <ins> // we make requests to all resources, don't log warnings about deprecated ones restclient.SetDefaultWarningHandler(restclient.NoWarnings{}) </ins> kubeClient := clientset.NewForConfigOrDie(kubeClientConfig) go func() {

Discussion:
Improve the to ensure that the expected storage version for a resource is one understood by previous releases. We have API testdata from prior versions available in When checking each group/version/kind in the test: accumulate all the versions of the group/kind available in previous (non-HEAD) releases if there is a beta or stable version of the group/kind available in previous releases, then the storage version must be in the set of previously available versions It is too easy to accidentally change the storage version prematurely and edit the test/integration/etcd test to match the bug cc
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
Change:
"//pkg/util/sysctl:go_default_library", "//pkg/util/version:go_default_library", "//vendor/github.com/golang/glog:go_default_library", <del> "//vendor/golang.org/x/sys/unix:go_default_library", </del> "//vendor/k8s.io/api/core/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/types:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/sets:go_default_library",

Discussion:
https://k8s- https://k8s- cc: /priority failing-test
Sorry, but I will fix it ASAP.
/assign
PR is already sent. Wating for CI report...
Change:
Into(result) return } <ins> // CreateScale takes the representation of a scale and creates it.  Returns the server's representation of the scale, and an error, if there is any. func (c *clusterTestTypes) CreateScale(ctx context.Context, clusterTestTypeName string, scale *autoscalingv1.Scale, opts metav1.CreateOptions) (result *autoscalingv1.Scale, err error) { result = &autoscalingv1.Scale{} err = c.client.Post(). Resource("clustertesttypes"). Name(clusterTestTypeName). SubResource("scale"). VersionedParams(&opts, scheme.ParameterCodec). Body(scale). Do(ctx). Into(result) return } </ins>

Discussion:
What happened: Test create method for non-namespaced subresources generate invalid code. I have the following code generation annotations: which generated test method with generated fake client: What you expected to happen: It should be: How to reproduce it (as minimally and precisely as possible): Generate clients for non-namespaced resources with subresources (like scale) like this: /sig api-machinery /area code-generator /assign
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: What you expected to happen: It should be: How to reproduce it (as minimally and precisely as possible): Generate clients for non-namespaced resources with subresources (like scale) like this: /sig api-machinery /area code-generator /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
/assign
/triage accepted
Change:
// The Kubelet panics if either kube-reserved or system-reserved is not set // when CPU Manager is enabled. Set cpu in kube-reserved > 0 so that // kubelet doesn't panic. <ins> if newCfg.KubeReserved == nil { newCfg.KubeReserved = map[string]string{} } </ins> if _, ok := newCfg.KubeReserved["cpu"]; !ok { newCfg.KubeReserved["cpu"] = "200m" }

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: Test failed when running CPU Manager node e2e test on Ubuntu 16.04 locally, and show this panic message: What you expected to happen: Tests passed. How to reproduce it (as minimally and precisely as possible): Run this node e2e test, use the following command: Anything else we need to know?: I think this is because the following codes: is . I will send a PR to fix this after it is confirmed. /sig node /assign PTAL, Thanks!
Thanks for the bug report. Reproduced successfully. It looks like the response body may have changed from empty map to null, which caused this to break. In any case, suggested adding the fix to his pending PR here:
Hi, have fixed this, lgtm.
Change:
echo 'No need to refresh sudo credentials' else echo 'Updating sudo credentials' <del> sudo --validate || exit 1 </del> <ins> sudo -v || exit 1 </ins> fi # FOCUS is ginkgo focus to select which tests to run. By default, FOCUS is

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 run , I founded failed. What you expected to happen: Test passed How to reproduce it (as minimally and precisely as possible): Sudo version 1.8.6p7 Anything else we need to know?: Environment: Kubernetes version (use ): 1.17 Cloud provider or hardware configuration: OS (e.g: ):centos Kernel (e.g. ):Linux elk-141 4.9.6- SMP Wed Mar 1 18:39:23 CST 2017 x8664 x8664 x8664 GNU/Linu Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc
/sig node
Change:
g.eventRecorder.Event(svc, v1.EventTypeWarning, "ILBOptionsIgnored", "Internal LoadBalancer options are not supported with Legacy Networks.") options = ILBOptions{} } <ins> if !g.AlphaFeatureGate.Enabled(AlphaFeatureILBCustomSubnet) { if options.SubnetName != "" { g.eventRecorder.Event(svc, v1.EventTypeWarning, "ILBCustomSubnetOptionIgnored", "Internal LoadBalancer CustomSubnet options ignored as the feature gate is disabled.") options.SubnetName = "" } } </ins> loadBalancerName := g.GetLoadBalancerName(context.TODO(), clusterName, svc) sharedBackend := shareBackendService(svc)

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: ILB ip addresses come from the subnet that the K8s cluster uses. There is no ability to specify a different subnet. What you expected to happen: ILB ip addresses should be allocated from a different subnet if specified. 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: GCE OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/area platform/gce /assign
/sig network
Change:
e2e_storage_test_environment: '$(echo "$E2E_STORAGE_TEST_ENVIRONMENT" | sed -e "s/'/''/g")' kube_uid: '$(echo "${KUBE_UID}" | sed -e "s/'/''/g")' initial_etcd_cluster: '$(echo "${INITIAL_ETCD_CLUSTER:-}" | sed -e "s/'/''/g")' <del> etcd_quorum_read: '$(echo "${ETCD_QUORUM_READ:-}" | sed -e "s/'/''/g")' </del> hostname: $(hostname -s) enable_default_storage_class: '$(echo "$ENABLE_DEFAULT_STORAGE_CLASS" | sed -e "s/'/''/g")'

Discussion:
Slack user "nalin" reported an issue Looking at the code this makes sense. Will fix.
For anyone following along, the fix for this bug unfortunately didn't get cherrypicked because of a process issue, and is broken until 1.5.2. cc
I just the new lines from As a temperatur fix ONLY. If anyone like me dont want to wait. Worked like at charm for AWS cluster setup. :)
A quick note, just as confirmation: the above temporary fix does resolve the issue for AWS - even though it's a change to a GCE-related file (cluster/gce/configure-). It seems that the GCE files are used for certain aws functions.
In based AWS deployment, the script is shared between AWS and GCE.
Also, this fix was cherry-picked into the branch a while ago, so instead of manually adding the lines, you can also just checkout the branch and run from there.
Change:
--master="http://${API_HOST}:${API_PORT}" >"${SCHEDULER_LOG}" 2>&1 & SCHEDULER_PID=$! <del> echo "Local Kubernetes cluster is running. Press Ctrl-C to shut it down." echo "Logs: " echo "  ${APISERVER_LOG}" echo "  ${CTLRMGR_LOG}" echo "  ${KUBELET_LOG}" echo "  ${PROXY_LOG}" echo "  ${SCHEDULER_LOG}" </del> <ins> cat <<EOF Local Kubernetes cluster is running. Press Ctrl-C to shut it down. Logs: ${APISERVER_LOG} ${CTLRMGR_LOG} ${KUBELET_LOG} ${PROXY_LOG} ${SCHEDULER_LOG} To start using your cluster, open up another terminal/tab and run: export KUBERNETES_PROVIDER=local cluster/kubectl.sh EOF </ins> cleanup() {

Discussion:
When starting locally a cluster from source by running hack/local-up-, kubecfg and kubectl require gcloud in order to work. It doesn't make sense to depend on gcloud when running a cluster from source locally in a dev env, hence please provide instructions to make kubectl/kubecfg work locally without gcloud in this local setup.
Doesn't make sense for vagrant either
Have you read getting started guide? In section. I think it's recently :)
I think the issue is that kube up local / vagrant shouldn't require gcloud at all ----- Original Message -----
It shouldn't. I suspect that it is that defaults to gce. I'm going to take a run through the experience/guides and make sure this is clear and there is no gcloud required.
I had done some work on making a real cluster provider for local, but didn't merge it, since it didn't look like it would be sufficient to make e2e work. However, if it would make it easier to run locally, I could check it in. It's weird that the local setup lives in hack.
I think it'd be great to have a real provider for local, but I'm not sure it is a super high pri. I'm going to clarify the local script a little to close out this. -- let us know if doesn't fix it for you and we will investigate further.