jiebi/CodeConvo huggingface dataset:
Code change:
Not , but removed: Looking at this comment: this should be removed once the migration to lease in leader-election was done. Can this be removed already? I mean, the following 2 lines: Security folks internally were asking if we could get rid of this upstream if it is not needed anymore (if this "migration to lease in leader-election" was fully done)
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 sig-scheduling
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig sig-scheduling 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
/sig scheduling
/cc
/assign
Support for endpoints and configmap based leader election has been removed with this PR: Validation to error out leader elections configuration for resource lock type other than "lease" has been implemented in With this, it looks safe to remove the two lines mentioned in this issue.

Related discussion:
text: // TODO: scope this to the kube-system namespace rbacv1helpers.NewRule("create").Groups(coordinationGroup).Resources("leases").RuleOrDie(), rbacv1helpers.NewRule("get", "update").Groups(coordinationGroup).Resources("leases").Names("kube-scheduler").RuleOrDie(), <del> // TODO: Remove once we fully migrate to lease in leader-election. rbacv1helpers.NewRule("create").Groups(legacyGroup).Resources("endpoints").RuleOrDie(), rbacv1helpers.NewRule("get", "update").Groups(legacyGroup).Resources("endpoints").Names("kube-scheduler").RuleOrDie(), </del> // Fundamental resources rbacv1helpers.NewRule(Read...).Groups(legacyGroup).Resources("nodes").RuleOrDie(),
Code change:
Not , but removed: Looking at this comment: this should be removed once the migration to lease in leader-election was done. Can this be removed already? I mean, the following 2 lines: Security folks internally were asking if we could get rid of this upstream if it is not needed anymore (if this "migration to lease in leader-election" was fully done)
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 sig-scheduling
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig sig-scheduling 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
/sig scheduling
/cc
/assign
Support for endpoints and configmap based leader election has been removed with this PR: Validation to error out leader elections configuration for resource lock type other than "lease" has been implemented in With this, it looks safe to remove the two lines mentioned in this issue.

Related discussion:
text: - apiGroups: - "" resources: <del> - endpoints verbs: - create - apiGroups: - "" resourceNames: - kube-scheduler resources: - endpoints verbs: - get - update - apiGroups: - "" resources: </del> - nodes verbs: - get
Code change:
Followup feedback from In a few e2e node tests (e.g. tests of deletion grace period) we have some busybox pods that wait for SIGTERM and perform some action like a small sleep to simulate SIGTERM taking some time. These tests follow the pattern of -- see The will block the SIGTERM handler from being run until after the time is elapsed. We should consider to remove the and instead use to avoid blocking the SIGTERM handler, see pattern followed in n/a n/a No response n/a n/a <details</details<details</details<details</details<details</details
/sig node /cc
/assign
/triage accepted

Related discussion:
text: Image:   imageutils.GetE2EImage(imageutils.BusyBox), Command: []string{"sh", "-c"}, Args: []string{` <ins> sleep 9999999 & PID=$! </ins> _term() { <ins> kill $PID </ins> echo "Caught SIGTERM signal!" <del> exit 0 </del> } trap _term SIGTERM <del> while true; do sleep 5; done </del> <ins> wait $PID exit 0 </ins> `, }, },
Code change:
Followup feedback from In a few e2e node tests (e.g. tests of deletion grace period) we have some busybox pods that wait for SIGTERM and perform some action like a small sleep to simulate SIGTERM taking some time. These tests follow the pattern of -- see The will block the SIGTERM handler from being run until after the time is elapsed. We should consider to remove the and instead use to avoid blocking the SIGTERM handler, see pattern followed in n/a n/a No response n/a n/a <details</details<details</details<details</details<details</details
/sig node /cc
/assign
/triage accepted

Related discussion:
text: } return priority } <ins> // getGracePeriodOverrideTestPod returns a new Pod object containing a container // runs a shell script, hangs the process until a SIGTERM signal is received. // The script waits for $PID to ensure that the process does not exist. // If priorityClassName is scheduling.SystemNodeCritical, the Pod is marked as critical and a comment is added. </ins> func getGracePeriodOverrideTestPod(name string, node string, gracePeriod int64, priorityClassName string) *v1.Pod { pod := &v1.Pod{ TypeMeta: metav1.TypeMeta{
Code change:
Followup feedback from In a few e2e node tests (e.g. tests of deletion grace period) we have some busybox pods that wait for SIGTERM and perform some action like a small sleep to simulate SIGTERM taking some time. These tests follow the pattern of -- see The will block the SIGTERM handler from being run until after the time is elapsed. We should consider to remove the and instead use to avoid blocking the SIGTERM handler, see pattern followed in n/a n/a No response n/a n/a <details</details<details</details<details</details<details</details
/sig node /cc
/assign
/triage accepted

Related discussion:
text: Image:   busyboxImage, Command: []string{"sh", "-c"}, Args: []string{` <del> _term() { echo "Caught SIGTERM signal!" while true; do sleep 5; done } trap _term SIGTERM while true; do sleep 5; done `}, </del> <ins> sleep 9999999 & PID=$! _term() { echo "Caught SIGTERM signal!" wait $PID } trap _term SIGTERM wait $PID `}, </ins> }, }, TerminationGracePeriodSeconds: &gracePeriod,
Code change:
No response No response /sig windows /kind failing-test
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig windows
i think this problem can be fixed when it imports os/net in Am i right?
I also found some other unit test bugs in CI, such as running linux-related tests on windows. I will try to fix them. /assign
/cc
Thanks for opening the issue! I didn't notice the failure through the testgrid dashboard. I've sent a PR here: . While fixing this issue, I noticed there's one unit test that was failing, so that PR also addresses that as well.
Yep, the imports you mentioned are needed. Keep in mind that imports are in alphabetical order. But in addition to that, there was another failing unit test which was masked by this import errors.

Related discussion:
text: "fmt" "net" "net/url" <ins> "os" </ins> "path/filepath" "strings" "syscall"
Code change:
No response No response /sig windows /kind failing-test
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig windows
i think this problem can be fixed when it imports os/net in Am i right?
I also found some other unit test bugs in CI, such as running linux-related tests on windows. I will try to fix them. /assign
/cc
Thanks for opening the issue! I didn't notice the failure through the testgrid dashboard. I've sent a PR here: . While fixing this issue, I noticed there's one unit test that was failing, so that PR also addresses that as well.
Yep, the imports you mentioned are needed. Keep in mind that imports are in alphabetical order. But in addition to that, there was another failing unit test which was masked by this import errors.

Related discussion:
text: // does NOT work in 1809 if the socket file is created within a bind mounted directory by a container // and the FSCTL is issued in the host by the kubelet. <ins> // If the file does not exist, it cannot be a Unix domain socket. if _, err := os.Stat(filePath); os.IsNotExist(err) { return false, fmt.Errorf("File %s not found. Err: %v", filePath, err) } </ins> klog.V(6).InfoS("Function IsUnixDomainSocket starts", "filePath", filePath) // As detailed in https://github.com/kubernetes/kubernetes/issues/104584 we cannot rely // on the Unix Domain socket working on the very first try, hence the potential need to
Code change:
No response No response /sig windows /kind failing-test
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig windows
i think this problem can be fixed when it imports os/net in Am i right?
I also found some other unit test bugs in CI, such as running linux-related tests on windows. I will try to fix them. /assign
/cc
Thanks for opening the issue! I didn't notice the failure through the testgrid dashboard. I've sent a PR here: . While fixing this issue, I noticed there's one unit test that was failing, so that PR also addresses that as well.
Yep, the imports you mentioned are needed. Keep in mind that imports are in alphabetical order. But in addition to that, there was another failing unit test which was masked by this import errors.

Related discussion:
text: import ( "fmt" "math/rand" <ins> "net" "os" </ins> "reflect" "runtime" "sync"
Code change:
<!-- 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: Following the example here: Everything here works when you use , but when using 1.27.1, I see the following panic: What you expected to happen: When downgrading, this works as expected: How to reproduce it (as minimally and precisely as possible): <!-- Please make sure you are able to reproduce the bug using a supported version and version skew of Kubernetes. See for which versions and are currently supported. --You will need a Kubernetes cluster with Agones installed (I'm testing on 1.25.x, as you can see above), then follow this quickstart: Anything else we need to know?: The is implemented as an API Extension, not a CRD -- which is probably where the issue lies. Looking at the line: There seems to be an assuming that there will be a under and , in - there should be some nil checks in there. Environment: Kubernetes client and server versions (use ): See above Cloud provider or hardware configuration: GKE OS (e.g: ): Linux
seems like an another edge case; Due to the server version is old and openapiv3 is returning empty?
Thanks for opening this issue /triage accepted
I'm digging into the Agones code, but I'm 99.4% sure we don't even implement openapiv3 at all for our api endpoint
Yep, confirmed -- I see a bunch of 404's in my API Extension logs for requests for
/transfer kubernetes /kind regression
/sig cli /assign
I can also work on tomorrow if Sean can not get time to look at it
If nothing else, this does also force me to publish an openapi spec for our API extension
not sure if needed to handle nils inside the schema better, or if didn't fall back to v2 correctly in the absence of v3 data
It appears to be the former, where an OpenAPI V3 document is returned without , while the code assumes this field is non-nil.
seems like that should still fall back to v2
Can we get a kubectl -v8 to see what actually happens with downloading the OpenAPI?
As requested!
Thanks for the quick response. It looks like the OpenAPI V3 document is almost completely empty The code is expecting an Open API document with . I will have a fix out shortly.
I was digging through that - I found that really interesting. We only expose an basically empty spec for the api extension. It's always "just worked", so never needed to update it. I am curious where K8s is even getting the something that it is outputting for , but that's a side note.

Related discussion:
text: // the PATCH end-point. Returns true if the query param is supported by the // spec for the passed GVK; false otherwise. func supportsQueryParamV3(doc *spec3.OpenAPI, gvk schema.GroupVersionKind, queryParam VerifiableQueryParam) bool { <ins> if doc == nil || doc.Paths == nil { return false } </ins> for _, path := range doc.Paths.Paths { // If operation is not PATCH, then continue. op := path.PathProps.Patch
Code change:
<!-- 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: Following the example here: Everything here works when you use , but when using 1.27.1, I see the following panic: What you expected to happen: When downgrading, this works as expected: How to reproduce it (as minimally and precisely as possible): <!-- Please make sure you are able to reproduce the bug using a supported version and version skew of Kubernetes. See for which versions and are currently supported. --You will need a Kubernetes cluster with Agones installed (I'm testing on 1.25.x, as you can see above), then follow this quickstart: Anything else we need to know?: The is implemented as an API Extension, not a CRD -- which is probably where the issue lies. Looking at the line: There seems to be an assuming that there will be a under and , in - there should be some nil checks in there. Environment: Kubernetes client and server versions (use ): See above Cloud provider or hardware configuration: GKE OS (e.g: ): Linux
seems like an another edge case; Due to the server version is old and openapiv3 is returning empty?
Thanks for opening this issue /triage accepted
I'm digging into the Agones code, but I'm 99.4% sure we don't even implement openapiv3 at all for our api endpoint
Yep, confirmed -- I see a bunch of 404's in my API Extension logs for requests for
/transfer kubernetes /kind regression
/sig cli /assign
I can also work on tomorrow if Sean can not get time to look at it
If nothing else, this does also force me to publish an openapi spec for our API extension
not sure if needed to handle nils inside the schema better, or if didn't fall back to v2 correctly in the absence of v3 data
It appears to be the former, where an OpenAPI V3 document is returned without , while the code assumes this field is non-nil.
seems like that should still fall back to v2
Can we get a kubectl -v8 to see what actually happens with downloading the OpenAPI?
As requested!
Thanks for the quick response. It looks like the OpenAPI V3 document is almost completely empty The code is expecting an Open API document with . I will have a fix out shortly.
I was digging through that - I found that really interesting. We only expose an basically empty spec for the api extension. It's always "just worked", so never needed to update it. I am curious where K8s is even getting the something that it is outputting for , but that's a side note.

Related discussion:
text: "k8s.io/client-go/openapi/cached" "k8s.io/client-go/openapi/openapitest" "k8s.io/client-go/openapi3" <ins> "k8s.io/kube-openapi/pkg/spec3" </ins> ) func TestV3SupportsQueryParamBatchV1(t *testing.T) {
Code change:
This pertains more for clusters running in GCP but not necessarily in a GKE environment. Clusters that using a CNI supporting overlay such as Calico, do not need explicit routes to be created on the infrastructure level, meaning that the route controller should not be necessary. The following snippet sets the condition for new GCE nodes when a new node is picked up by the node controller. This condition is supposed to be removed later by the route controller in However, as stated above there are cases where the route controller is not needed and should not be running. When Calico is deployed in such a way that the calico-node pods are ignoring any and all taints including the cloudprovider's taint (which we consider reasonable for a system pod such as calico), the above check creates the following race condition: a Calico pod may start and set the node network conditions ( to false) before the node controller reconciles the node. After that the node controller picks up the node and sets the condition to an otherwise healthy node. Leaving aside the race condition itself, I have to ask whether the check is meaningful in the first place. AFAIK, the kubelet in Kubelet only sets the condition for provider, but clusters should already be using kubelet with cloudprovider= For the node controller to not set the condition unnecessarily. An easy way to do it with a custom CCM image is to introduce some delay in the node sync loop, enough for pods such as calico-node to start on that node. No response <details</details<detailsGCP </details<details</details<details</details<details</details<detailsCalico </details
This should be fixed by /cc
/sig cloud-provider /sig network /assign
/triage accepted

Related discussion:
text: }) err = clientretry.RetryOnConflict(UpdateNodeSpecBackoff, func() error { <del> var curNode *v1.Node if cnc.cloud.ProviderName() == "gce" { // TODO(wlan0): Move this logic to the route controller using the node taint instead of condition // Since there are node taints, do we still need this? // This condition marks the node as unusable until routes are initialized in the cloud provider if err := nodeutil.SetNodeCondition(cnc.kubeClient, types.NodeName(nodeName), v1.NodeCondition{ Type:               v1.NodeNetworkUnavailable, Status:             v1.ConditionTrue, Reason:             "NoRouteCreated", Message:            "Node created without a route", LastTransitionTime: metav1.Now(), }); err != nil { return err } // fetch latest node from API server since GCE-specific condition was set and informer cache may be stale curNode, err = cnc.kubeClient.CoreV1().Nodes().Get(context.TODO(), nodeName, metav1.GetOptions{}) if err != nil { return err } } else { curNode, err = cnc.nodeInformer.Lister().Get(nodeName) if err != nil { return err } </del> <ins> curNode, err = cnc.nodeInformer.Lister().Get(nodeName) if err != nil { return err </ins> } newNode := curNode.DeepCopy()
Code change:
Add the following to be safe sysctls: net.ipv4.tcpfintimeout net.ipv4.tcpkeepaliveintvl net.ipv4.tcpkeepaliveprobes These are related settings to net.ipv4.tcpkeepalivetime that was enabled in These are related ipv4 TCP settings for tuning network connections between a client and a pod.
/sig network
May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node. /sig nodes 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
/sig node
I adjusted it with the plugin.
Would this change apply at the node level or the pod level? I assumed it would be at the pod level, and should not affect any other pods--however Kubernetes does not natively have any limits on network connections that I am aware of--but only the pod with the changed net settings would be affected.
To verify that a sysctl has an effect on other pods, we need to verify that it's a namespace sysctl.
Here's a simple test Use net.ipv4.tcpfintimeout sysctl to create a container check if it set on the host =It is the default value on host run another container attach to the network namespace of the one where the sysctl is set =results in sysctl being set Verify in another container under a different network namespace that it is not set =It is the default value According to the test results, net.ipv4.tcpfintimeout is a namespaced sysctl
I likewise verified and , which are also namespaced sysctl, and I believe we can add them to the safe sysctl /assign
Probably need to wait for to finish before start working on it
/triage accepted

Related discussion:
text: name: "net.ipv4.tcp_keepalive_time", // refer to https://github.com/torvalds/linux/commit/13b287e8d1cad951634389f85b8c9b816bd3bb1e. kernel: "4.5", <ins> }, { // refer to https://github.com/torvalds/linux/commit/1e579caa18b96f9eb18f4f5416658cd15f37c062. name:   "net.ipv4.tcp_fin_timeout", kernel: "4.6", }, { // refer to https://github.com/torvalds/linux/commit/b840d15d39128d08ed4486085e5507d2617b9ae1. name:   "net.ipv4.tcp_keepalive_intvl", kernel: "4.5", }, { // refer to https://github.com/torvalds/linux/commit/9bd6861bd4326e3afd3f14a9ec8a723771fb20bb. name:   "net.ipv4.tcp_keepalive_probes", kernel: "4.5", </ins> }, }