jiebi/CodeConvo huggingface dataset:
Change:
} ?> ``` <del> To play with the service itself, find the name of a frontend, grab the external IP of that host from the [Google Cloud Console][cloud-console], and visit `http://<host-ip>:8080`. Note, you may need to open the firewall for port 8080 using the [console][cloud-console] or the `gcloud` tool. </del> <ins> To play with the service itself, find the name of a frontend, grab the external IP of that host from the [Google Cloud Console][cloud-console], and visit `http://<host-ip>:8080`. You may need to open the firewall for port 8080 using the [console][cloud-console] or the `gcloud` tool. </ins> [cloud-console]: https://console.developer.google.com

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: I am running an admission webhook using If there it has been hours since the last mutating request to the webhook, then the next mutating request will take many seconds to be processed. This may even take long enough to have the request time out. What you expected to happen: A request takes approximately the same amount of time to be processed regardless of how long it has been since the last request. How to reproduce it (as minimally and precisely as possible): Create an API server for handling a new API group. Wait a couple hours. Send a CREATE request to the API server. Observe that the CREATE request takes a few seconds to complete. Anything else we need to know?: This is the offending code. It must loop through once for every second since the last request. Environment: Kubernetes version (use ): 1.19.0
/sig api-machinery
I thought we'd already merged a fix for this from before the release?
I assume that the fix was supposed to be From my understanding, those changes only are in effect if the apiserver is running with priority and fairness enabled. In my situation, I do not have that enabled.
Ack, if we have the problem in both places we need the fix in both places :)
/triage accepted
I think we have fixed this in , do you guys agree?
Change:
"k8s.io/apimachinery/pkg/util/clock" "k8s.io/apimachinery/pkg/util/wait" apiserverserviceaccount "k8s.io/apiserver/pkg/authentication/serviceaccount" <ins> "k8s.io/client-go/discovery" </ins> clientset "k8s.io/client-go/kubernetes" v1core "k8s.io/client-go/kubernetes/typed/core/v1" restclient "k8s.io/client-go/rest"

Discussion:
Ran kube-controller-manager with and observed this in the log every 30 seconds: This is also happening in 1.20, 1.19, and 1.18 The GC and quota clients look up discovery information every 30 seconds. They have a QPS of 20 requests per second and a burst of 30 requests. Default configuration of kube-controller-manager runs without constant throttling warnings. /sig api-machinery
/assign /triage accepted
Change:
for _, t := range tests { t := t ginkgo.It(t.name, func(ctx context.Context) { <ins> // Some metrics use CSI driver name as a label, which is "csi-mock-" + the namespace name. volumePluginLabel := "{volume_plugin="kubernetes.io/csi/csi-mock-" + f.Namespace.Name + ""}" // All SELinux metrics. Unless explicitly mentioned in test.expectIncreases, these metrics must not grow during // a test. allMetrics := sets.NewString( "volume_manager_selinux_container_errors_total", "volume_manager_selinux_container_warnings_total", "volume_manager_selinux_pod_context_mismatch_errors_total", "volume_manager_selinux_pod_context_mismatch_warnings_total", "volume_manager_selinux_volume_context_mismatch_errors_total"+volumePluginLabel, "volume_manager_selinux_volume_context_mismatch_warnings_total"+volumePluginLabel, "volume_manager_selinux_volumes_admitted_total"+volumePluginLabel, ) </ins> if framework.NodeOSDistroIs("windows") { e2eskipper.Skipf("SELinuxMount is only applied on linux nodes -- skipping") }

Discussion:
[It] [sig-storage] CSI Mock selinux on mount metrics SELinuxMount metrics [LinuxOnly][Feature:SELinux][Feature:SELinuxMountReadWriteOncePod][Serial] warning is not bumped on two Pods with the same context on RWO volume [sig-storage] [It] [sig-storage] CSI Mock selinux on mount metrics SELinuxMount metrics [LinuxOnly][Feature:SELinux][Feature:SELinuxMountReadWriteOncePod][Serial] warning is bumped on two Pods with a different context on RWO volume [sig-storage] Sample failure: October 25, 2023 It fails since The PR a label to some SELinux metric and the tests do not count with that. No response /sig storage
/assign /triage accepted
Change:
if filePath == m.checkpointFile() { continue } <del> stat, err := os.Stat(filePath) </del> <ins> // TODO: Until the bug - https://github.com/golang/go/issues/33357 is fixed, os.stat wouldn't return the // right mode(socket) on windows. Hence deleting the file, without checking whether // its a socket, on windows. stat, err := os.Lstat(filePath) </ins> if err != nil { klog.ErrorS(err, "Failed to stat file", "path", filePath) continue } <del> if stat.IsDir() || stat.Mode()&os.ModeSocket == 0 { </del> <ins> if stat.IsDir() { </ins> continue } err = os.RemoveAll(filePath)

Discussion:
Since I upgraded my kubernetes cluster from to , kubelet fails to restart on Windows. The error messages in the logs are: I expected kubelet to start even if the file exists, this was the behavior in the previous versions. a Windows Kubernetes Node again and watch it fail due to the file already existing. I think this Issue has to do with the commit where socket files are not removed anymore causing the start to fail because the file already exists. <details</detailsOn Premise / No Cloud Provider <details</detailsNo response <detailsContainerd Version: 1.7.20 </detailsNo response
/sig windows
/area kubelet
/cc
/sig node /triage accepted /priority critical-urgent
I was able to reproduce this
/assign Given the severity, assigning to you.
reverting fixes the issue
The reason for the issue is that kubernetes used go , whilst the release uses : / The fix for has been implemented in go (and its rc) and has not been backported to . Commit of fix: So updating kubernetes back to go fixes this issue and resolves the TODO in
/reopen The PR needs to be cherry-picked and released before we can actually close this.
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
/close Cherry pick was merged so this should be good now. This will be in v.1.31.1 when that goes out.
Closing this issue. <detailsIn response to : /close 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:
logger.Error(err, "waiting for handlers to sync") } <ins> close(handlerSyncReadyCh) </ins> logger.V(3).Info("Handlers synced") } if !cc.ComponentConfig.DelayCacheUntilActive || cc.LeaderElection == nil {

Discussion:
Quoted from 's Splitting healthz/ into livez/ and readyz/
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 scheduling
I read all the content of the PR comment and am willing to work on this issue Do we need to continue some discussion for this issue
Hi , thanks for offering your help. But I was working in progress before knowing you can work on this. However, please feel free to contribute the similar issue
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
} } <del> if ok, failReason, failMessage := kl.canAdmitPod(otherActivePods, pod); !ok { </del> <ins> if ok, failReason, failMessage := kl.canAdmitPod(otherActivePods, podCopy); !ok { </ins> // Log reason and return. Let the next sync iteration retry the resize <del> klog.V(3).InfoS("Resize cannot be accommodated", "pod", pod.Name, "reason", failReason, "message", failMessage) return false, nil, v1.PodResizeStatusDeferred </del> <ins> klog.V(3).InfoS("Resize cannot be accommodated", "pod", podCopy.Name, "reason", failReason, "message", failMessage) return false, podCopy, v1.PodResizeStatusDeferred </ins> } <del> podCopy := pod.DeepCopy() </del> for _, container := range podCopy.Spec.Containers { idx, found := podutil.GetIndexOfContainerStatus(podCopy.Status.ContainerStatuses, container.Name) if found {

Discussion:
mutates the pod object in place (vs creating a copy first). That's illegal and can cause data races or potentially panics (the panic is unlikely here but I can't rule it out). This line should be: This should be fixed because we might serialize the object in the middle of this from somewhere else and if the object changes midway the protobuf object we create may not be valid, leading to panics in kubelets with this gate turned on. /sig node /priority critical-urgent /kind bug /assign No mutation of pod objects from within methods (in fact no mutation of should occur in most loops). 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
ACK. I'll fix it shortly.
is similar. is my try for both data races that we found.
One small , thanks.
Please review
This Issue/PR has been marked as release blocker. Please have the fix merged by eod today otherwise the feature has to be reverted. For the Issue/PR owner: please have a revert/feature disable PR open today in case the fix failed to get in. Thank you! See the -- Kubernetes 1.27 release manager
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/client/metrics" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/fields" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/runtime"

Discussion:
Currently we do not measure latency for REST operations. This is important for any component that performs non-watch operations (scheduler, controllers, kubelet). This is also prerequisite to actually make sure that all API calls take less than 1 sec ( ).
The apiserver is already , including for REST operations. You can scrape the metrics by hitting the /metrics HTTP endpoint.
Sorry, I was not clear in the description. I'm more interested on the client side and with more details so that I can measure things like: how long it takes to write bindings in scheduler how long it takes to update status in kubelet I'd think about it as a counterpart for apiserver stats.
Change:
responses: 200: body: <del> application/json: example: !include examples/pod-list.json </del> <ins> example: !include examples/pod-list.json </ins> post: description: Create a new pod. currentState is ignored if present. body: <del> json/application: schema: !include doc/pod-schema.json example: !include examples/pod.json </del> <ins> schema: !include doc/pod-schema.json example: !include examples/pod.json </ins> /{podId}: get:

Discussion:
Starting a large data set (32gb allocated, 4gb resident) in the api server causes about 7.5gb allocations of . The tree for that shows: This appears to be due to openapi aggregation. If there is an easy fix in 1.7 it might be worth it. Otherwise this should be addressed for 1.8.
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
This is all API server startup - for small clusters it's about 20-60% of startup time
Most of those are that is the library we used to convert our spec to proto. The key is this line: Do you have any idea how we can get a better space time/complexity here?
I have a PR for that now.
Fixed in
Even without aggregation, starting and serving OpenAPI docs was a huge chunk of startup time. The linked change makes it disappear.
This should not be related to aggregation at all (as far as I can tell from that tree). Thanks for the fix
Thanks, it's in gnostic master now.
Change:
} transformers := []rest.TransformFunc{p.applyPatch, p.applyAdmission, dedupOwnerReferencesTransformer} <del> if scope.FieldManager != nil { transformers = append(transformers, fieldmanager.IgnoreManagedFieldsTimestampsTransformer) } </del> wasCreated := false p.updatedObjectInfo = rest.DefaultUpdatedObjectInfo(nil, transformers...)

Discussion:
Sending a patch built from a typed client to SSA will force a write to etcd (and bump resourceVersion) since creationTimestamp is serialized to null. This is a follow-up of which doesn't solve the issue properly. Sending a no-op SSA request with creationTimestamp to null shouldn't do anything Kubectl apply an object with creationTimestamp null twice and see that it updates the object. Probably something like this would cause it:
/sig api-machinery /wg api-expression /triage accepted /assign /priority important-soon
Change:
} } <del> func (i *indexedWatchers) deleteWatcher(number int, scope namespacedName, value string, supported bool) { </del> <ins> func (i *indexedWatchers) deleteWatcher(number int, scope namespacedName, value string, supported bool, done func(*cacheWatcher)) { </ins> if supported { <del> i.valueWatchers[value].deleteWatcher(number) </del> <ins> i.valueWatchers[value].deleteWatcher(number, done) </ins> if len(i.valueWatchers[value]) == 0 { delete(i.valueWatchers, value) } } else { <del> i.allWatchers[scope].deleteWatcher(number) </del> <ins> i.allWatchers[scope].deleteWatcher(number, done) </ins> if len(i.allWatchers[scope]) == 0 { delete(i.allWatchers, scope) }

Discussion:
A data race manifested in job link: NA NA No response No response No response /sig api-machinery
/cc
/assign
ack, fixing ...
/triage accepted
Change:
if len(labelSpec) != 2 { return nil, fmt.Errorf("unexpected label spec: %s", labelSpecs[ix]) } <ins> if len(labelSpec[0]) == 0 { return nil, fmt.Errorf("unexpected empty label key") } </ins> labels[labelSpec[0]] = labelSpec[1] } return labels, nil

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: construct a string for labels, and let consume it. For example, suppose label string is , then this function will return a map which indicates a label . construct a string for portProtocols, and let consume it. For example, suppose portProtocols string is , then this function will return a map which indicates a pair . What you expected to happen: I assume the key of a label should not be an empty string since it makes no sense. I assume neither the nor the of pair should not be an empty string since it makes no sense. 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: /area kubectl
If it's a bug, I can help fix it.
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 cli
Change:
func TestGetEventsForTimePeriod(t *testing.T) { myEventHolder, myRequest, fakeEvent, fakeEvent2 := initializeScenario(t) <del> myRequest.StartTime = createOldTime(t).Add(-1 * time.Second * 10) myRequest.EndTime = createOldTime(t).Add(time.Second * 10) </del> <ins> myRequest.StartTime = time.Now().Add(-1 * time.Second * 10) myRequest.EndTime = time.Now().Add(time.Second * 10) </ins> myRequest.EventType[info.EventOom] = true myEventHolder.AddEvent(fakeEvent)

Discussion:
I have some reports of a Node reporting a a resource capacity for cpu as a negative value. Any idea why cpu could report as a negative value? Is this an expected normal outcome? In its current state, it prevents any pods from being scheduled to that Node. Tips on how to debug further are appreciated. - any ideas?
Can you check machineInfo on Cadvisor or kubelet on the node?
a.k.a:
It is a bug in cAdvisor side. I am assigning it to you :-)
here is contents of /proc/cpuinfo Pertinent pieces of a log:
Machine is AWS instance if that matters....
We build the topology from system/cpu info. I think we can return partial topology information and ignore caches if its not present. This isn't a recent change though. Is it happening on just a single machine? I'll file a cAdvisor issue.
Can you link the referenced issue once created?
Re-assigning to since he's working on google/cadvisor
Could be this was caused by getting a Node on EC2 with old hypervisor, and I am the first victim...
That sounds likely. Most of the cache information is there in /proc/cpuinfo. So looks like the sysfs bits are disabled.
Can you try this cadvisor image on your machine and check /api/v1.3/machine output: sudo docker run  --volume=/:/rootfs:ro  --volume=/var/run:/var/run:rw  --volume=/sys:/sys:ro  --volume=/var/lib/docker/:/var/lib/docker:ro  --publish=8080:8080  --detach=true  --name=cadvisor  jnagal/cadvisor:canary
hmm
ah, selinux :( You'll need to run it with --privileged, I think. who's been dealing with it.
No luck with --privileged either on this box...
This has to do with SELinux, I think we had to disable it for this to work (some of our mounts are being denied). We're working on a better solution... This is not a problem in Kubernetes since we don't run Kubelet/cAdvisor in a Docker container.
ok, unfortunately, i have managed to kill docker on the box in question, and i cannot get the daemon to restart right now so I am not sure when that box will be available to debug against again.

I can provide an environment with a similar issue if required.
The fix is checked in to head. Can you build the binary and try?
Change:
framework.ExpectNoError(err) beforeKC = kc } <ins> // show hidden metrics for release 1.22 beforeKC = updateShowHiddenMetricsForVersion(beforeKC, "1.22") </ins> // reset the node's assigned/active/last-known-good config by setting the source to nil, // so each test starts from a clean-slate (&nodeConfigTestCase{

Discussion:
This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
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
/cc
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon
Change:
return &azureToken{ token:       *token, <ins> environment: ts.environment.Name, </ins> clientID:    ts.clientID, tenantID:    ts.tenantID, apiserverID: ts.apiserverID,

Discussion:
What happened: AAD support in kubectl does not work for sovereign cloud The 'environment' parameter was introduced to support sovereign cloud, but it works in first round. The 'environment' value is not persisted, so follow-up requests will fail. What you expected to happen: 'environment' parameter persisted in kubectl config file. How to reproduce it (as minimally and precisely as possible): Use kubectl to connect to Azure sovereign cloud, make the token expire, and do auth. Anything else we need to know?: Environment: Kubernetes version (use ): 1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
There are no sig labels on this issue. Please add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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