jiebi/CodeConvo huggingface dataset:
Change:
kubectl delete clusterrolebinding kube-aggregator:system:kube-aggregator > /dev/null 2>&1 || true kubectl create clusterrolebinding kube-aggregator:system:auth-delegator --clusterrole=system:auth-delegator --serviceaccount=kube-public:kube-aggregator kubectl create clusterrolebinding kube-aggregator:system:kube-aggregator --clusterrole=system:kube-aggregator --serviceaccount=kube-public:kube-aggregator <del> kubectl delete rolebinding kube-aggregator:authentication-reader > /dev/null 2>&1 || true </del> <ins> kubectl delete rolebinding -n kube-system kube-aggregator:authentication-reader > /dev/null 2>&1 || true </ins> kubectl create rolebinding -n kube-system kube-aggregator:authentication-reader --role=extension-apiserver-authentication-reader --serviceaccount=kube-public:kube-aggregator # make sure the resources we're about to create don't exist

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG Create/delete rolebinding kube-aggregator:authentication-reader in different namespace cause to the failure detail:
Change:
elapsedSeconds := elapsed.Seconds() cleanContentType := cleanContentType(contentType) requestCounter.WithLabelValues(reportedVerb, dryRun, group, version, resource, subresource, scope, component, cleanContentType, codeToString(httpCode)).Inc() <ins> // MonitorRequest happens after authentication, so we can trust the username given by the request info, ok := request.UserFrom(req.Context()) if ok && info.GetName() == user.APIServerUser { apiSelfRequestCounter.WithLabelValues(reportedVerb, resource, subresource).Inc() } </ins> if deprecated { deprecatedRequestGauge.WithLabelValues(group, version, resource, subresource, removedRelease).Set(1) audit.AddAuditAnnotation(req.Context(), deprecatedAnnotationKey, "true")

Discussion:
Currently we don't have an easy way of determining what number of requests are apiserver self-requests. This has historically bitten us, since we used to have a 50(?) QPS limit on apiserver self-requests (which thus has been removed). Even so, it would be a good idea to know this generally, since this may be helpful in pinpointing performance regressions for apiserver. /sig api-machinery instrumentation
Can this issue be considered a newbie one? I'm hunting for issues which might be a good first PR.
In the triage meeting was mentioned that would be good to have similar issues to track other well known actors like controller-manager and kubelet. But let's keep this one for api-server calling itself to have it done. /cc
/cc
Change:
} } <del> return c.updateInstanceSecurityGroupsForNLB(loadBalancerName, nil, nil, nil) </del> <ins> return c.updateInstanceSecurityGroupsForNLB(loadBalancerName, nil, nil, nil, nil) </ins> } lb, err := c.describeLoadBalancer(loadBalancerName)

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: For each NLB created, K8s creates an ingress rule on the node group's security group for each port exposed for each CIDR attached to the VPC to allow health checks to succeed. AWS limits the number of rules per security group to 60 by default. This quota is adjustable but multiplied by the quota for security groups per network interface cannot exceed 1000. I have a VPC with 16 CIDR blocks attached to it and a quota for rules per security group set to 80. Each NLB created adds 18 new rules (16 for Health Check, 1 for Client, and 1 for MTU) to the node group's security groups. This high number of unnecessary rules created makes it impossible to create more than 4 NLBs per node group (if each one has a single port exposed). What you expected to happen: For the health check to succeed, the NLB must be able to ping the node port for the service on the cluster's node group. So the node group's security group just needs an inbound rule for each ENI of the NLB, making the number of rules necessary on the cluster's node group directly proportional to the number of AZs the NLB is configured. How to reproduce it (as minimally and precisely as possible): Create a VPC on AWS with 8 CIDRs attached to it; Create a K8s Cluster; Create a Network Load Balancer with 6 ports exposed; If the default quota of rules per security group has not been changed, the NLB creation will fail with RulesPerSecurityGroupLimitExceeded. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider
/area provider/aws
Change:
- name: vol mountPath: /scrub EOF <ins> # fixup the alternate registry if specified if [[ -n "${KUBE_ADDON_REGISTRY:-}" ]]; then sed -i -e "s@k8s.gcr.io@${KUBE_ADDON_REGISTRY}@g" "${PV_RECYCLER_OVERRIDE_TEMPLATE}" fi </ins> } function wait-till-apiserver-ready() {

Discussion:
Noticed this issue when looking at logs to figure out which images we use in a e2e test and from where. for example: Looks like it is from here:
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 storage cc
see background in and
slack discussion -
Looks like we can switch to see below:
looks like this image supports all the arch(es) we care about as well: !
Change:
<del> //go:build go1.14 // +build go1.14 /* Copyright 2020 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 flag import ( "crypto/tls" ) func init() { // support official IANA names as well on go1.14 ciphers["TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256"] = tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 ciphers["TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"] = tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 } </del>

Discussion:
Once we upgrade to go1.14, we can use the new CipherSuites and InsecureCipherSuites functions and CipherSuiteName function to build the supported cipher suite flags. /sig api-machinery
/sig auth
/cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
as the project was upgraded to go-1.14+ is that still something that needs to be done?
yes, these manually maintained maps should be swapped to the stdlib impls:
/assign
/triage accepted Thanks,
Change:
_, err = f.ClientSet.AppsV1().ReplicaSets(ns).Patch(context.TODO(), rsName, types.StrategicMergePatchType, []byte(rsPatch), metav1.PatchOptions{}) framework.ExpectNoError(err, "failed to patch ReplicaSet") <del> ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) </del> <ins> ctx, cancel := context.WithTimeout(context.Background(), 5*time.Minute) </ins> defer cancel() _, err = watchtools.Until(ctx, rsList.ResourceVersion, w, func(event watch.Event) (bool, error) { if rset, ok := event.Object.(*appsv1.ReplicaSet); ok {

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 --Since March 25th 2021, mostly windows jobs but a few others: 22 ci-kubernetes-e2e-windows-gce-2004 25 ci-kubernetes-e2e-windows-gce-20h2 17 ci-kubernetes-e2e-windows-containerd-gce 12 ci-kubernetes-e2e-windows-gce-2019 10 ci-kubernetes-kind-conformance-parallel-ipv6 5 ci-kubernetes-kind-e2e-parallel 4 ci-kubernetes-e2e-gci-gce-alpha-enabled-default Kubernetes e2e suite.[sig-apps] ReplicaSet Replace and Patch tests [Conformance] links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig windows /sig apps /kind flake
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
it's started failing consistently in Windows Dockershim
looks like there were updates to this tests which may have caused issues for Windows: was merged on the 24th and we started seeing flakes the day after
a 30 second time out that is running waiting for the pods to come up. from The windows nodes are still pulling the image at the 30 second timeout. Test failes at 10.11.31: You can see the image is still being pulled.
the pod for was finished pulling but hadn't started:
same for
It is definitely a timing issue for Windows (due to slower pull times) and looks to be a timing issue even on linux though it happens fewer times. We could increase the time out... I noticed it doesn't look like we have a consistent timeout for pods starting across tests.
Another option would be to use the which has a longer timeout (5 min) and is used earlier in the tests. Once running check the values on the replica set
/milestone v1.21
Change:
Requests: getNodeCPUAndMemoryCapacity(f), }) <ins> _, err = f.ClientSet.SchedulingV1().PriorityClasses().Create(systemCriticalPriority) gomega.Expect(err == nil || errors.IsAlreadyExists(err)).To(gomega.BeTrue(), "failed to create PriorityClasses with an error: %v", err) </ins> // Create pods, starting with non-critical so that the critical preempts the other pods. f.PodClient().CreateBatch([]*v1.Pod{nonCriticalBestEffort, nonCriticalBurstable, nonCriticalGuaranteed}) f.PodClientNS(kubeapi.NamespaceSystem).CreateSyncInNamespace(criticalPod, kubeapi.NamespaceSystem)

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Setting PodPriority directly when adminssion Priority enable,the Pod is rejected. To fix this, we need to create new priority classes for these tests. Which jobs are failing: Which test(s) are failing: I0822 19:01:41.165] should be able to create and delete a critical pod [It] Since when has it been failing: Testgrid link: Reason for failure: because adminssion Priority enableIf the priority class is not found, the Pod is rejected. Anything else we need to know:
/area e2e-test-framework /sig testing /kind bug /priority important-soon
This has now changed to this error: /reopen
Reopened this issue. <detailsIn response to : This has now changed to this error: /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
For reference: testgrid link /milestone v1.17
is this still in progress?
pr has updated, PTAL.
looks like has to merge for this to close
/milestone v1.18
Change:
return framework.NewStatus(framework.Error, err.Error()) } node := nodeInfo.Node() <del> // Debugging purpose: print the score for each node. // Score must be a pointer here, otherwise it's always 0. if klog.V(10) { defer func(score *int64, nodeName string) { klog.Infof("%v -> %v: PodTopologySpread NormalizeScore, Score: (%d)", pod.Name, nodeName, *score) }(&scores[i].Score, node.Name) } </del> if maxMinDiff == 0 { scores[i].Score = framework.MaxNodeScore

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Logging getting points for ALL priorities set in the default scheduler policy Why is this needed: We have Kubernetes v1.14 with a problem of planning pods for three nodes. The problem is that the scheduler unevenly distributes the pods across the nodes. For example, the CPU on two nodes Node02 and Node03 are 50% loaded, while the CPU on the third Node01 is not loaded at all. While that the pods continue to be planned on Node02 and Node03, but they are not planned on Node01 at all. Scheduler logs (maximum logging level) with uniform planning: and uneven planning: As you can see, the sum of points for the priorities BalancedResourceAllocation, LeastResourceAllocation, SelectorSpreadPriority, TaintTolerationPriority is the same in both cases, but the final result is different. There is no way to understand for what specific policy priorities Node01 did not get 3 points, for to be on a par with the others, because the set of points of some priorities is not logged.
/sig scheduling
I think maybe we missed some logs which can reflect the situation of giving the score. WDYT? If you confirmed, I want to handle this issue.
Thank you for the answer! Here is the full scheduling log (logging level 10): maybe I’m really missing something, but I don’t see information about other priorities here.
Missing scores may be due to some priority functions are using non-map-reduce style, so they didn't hit the printing logic. We can add a logging function there to help you better debugging it. However, the code gets refactored in recent releases, and 1.14 is out of our supporting cycles (only 1.15, ,1.16, 1.17). Can you upgrade to a newer version, or I can provide a code snippet for you to compile on your local 1.14 branch?
Thank you, but I already solved my problem by creating an additional scheduler with a custom scheduling policies for my cronjob. However, it would be cool if you the logging function in the supported versions :)
SG. I created to address this.
I'm running v1.23.8, and I've tried and I'm still not seeing any of the scoring output you in Am I doing something wrong?

Shouldn't this be available in v1.23?
is it possible there is only 1 node candidate after filtering? In that case, the scoring logic will be bypassed as it's meaningless to score for 1 node. If it's not the case, could you check the beginning of the scheduler log, to ensure is configured properly?
Change:
return } ref := &v1.ObjectReference{ <del> Kind:      "Pod", Name:      nsName.Name, Namespace: nsName.Namespace, </del> <ins> APIVersion: "v1", Kind:       "Pod", Name:       nsName.Name, Namespace:  nsName.Namespace, </ins> } tc.recorder.Eventf(ref, v1.EventTypeNormal, "TaintManagerEviction", "Cancelling deletion of Pod %s", nsName.String()) }

Discussion:
Events from node taint manager doesn't report involved object apiVersion: ! apiVersion is reported as other events. For example: ! a pod on node A (not master) off node A is reported, but without apiVersion in involvedObject. The apiVersion is not reported in The issue is still not fixed in master: ! <details</details<detailsIrrelevant </details<details</details<details</details<details</details<details</details
/sig node /sig apps
/assign In the latest version, the issue is confirmed
one suggestion you should wait for the corresponding SIG to triage the issue and accept it before sending PRs, the chances of your PR getting reviewed and approver are much higher
You are right sorry about that. It won’t happen again.
no no worries, it was a suggestion, is not that you did something wrong, but it is possible that your PR doesn't get reviews and you get frustrated
/remove-sig node please re-add if this is node-related issue
I think it is a node related issue. The root cause in taint manager.
/sig node
/assign /triage accepted
Change:
MinExternalEtcdVersion = "3.2.18" // DefaultEtcdVersion indicates the default etcd version that kubeadm uses <del> DefaultEtcdVersion = "3.5.3-0" </del> <ins> DefaultEtcdVersion = "3.5.4-0" </ins> // Etcd defines variable used internally when referring to etcd component Etcd = "etcd"

Discussion:
Please publish 3.5.4-0 image and update to to benefit from fix for , while still keeping v3.5.3 critical correctness fixes (, ). For recent PRs for update to etcd v3.5.3 see and
/sig release /sig api-machinery /kind bug
/cc /triage accepted
Hey, Can I work on this ? I'm a beginner, but all the good first issues are mostly assigned. Can you guide me on doing this ?
I am working on this. /assign
Hi I would like to work on Make sense to backport in v1.22, v1.23 & v1.24? Thanks!!
hi, it makes sense to me, but requires approval from dependency maintainers. i can only approve the kubeadm changes.
was this backported ?
Change:
proxier.endpointsSynced = true } <ins> func deleteEndpoints(proxier *Proxier, allEndpoints ...*v1.Endpoints) { for i := range allEndpoints { proxier.OnEndpointsDelete(allEndpoints[i]) } proxier.mu.Lock() defer proxier.mu.Unlock() proxier.endpointsSynced = true } </ins> func makeTestEndpoints(namespace, name string, eptFunc func(*v1.Endpoints)) *v1.Endpoints { ept := &v1.Endpoints{ ObjectMeta: metav1.ObjectMeta{

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: Two services referring the same endpoint. One of the services was deleted. This brought down the connectivity of the other service. What you expected to happen: The connectivity to service should continue to work How to reproduce it (as minimally and precisely as possible): two services referencing same endpoint one of the services connectivity is broken to the other service Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Do you mean a service referencing the same pod, or literally the same Endpoints object?
I meant service referencing the same pod.
/assign
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
Is this still an issue? If so, it would be helpful to get an answer to Jordan's question above. If this Service is referencing the same Endpoints object that would be a very different issue than if it was referencing the same Pod. /triage needs-information
This issue happens when multiple Services are referencing a same POD. I mean the same backend IP address but different ports. i.e. the POD is hosting two workloads on different ports.
/sig windows
Is this only observed in windows environments?
Yes this happens only on Windows environments
Thanks can you provide more information about the version of Kubernetes you're using? Do you know what proxier mode kube-proxy is running with? Maybe winkernel? I'm not as familiar with the Windows implementation here, adding to help debug this.

/assign
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
Change:
// TODO: get the real minion object of ourself, // and use the real minion name and UID. ref := &api.ObjectReference{ <del> Kind: "Minion", Name: kl.hostname, UID:  kl.hostname, </del> <ins> Kind:      "Minion", Name:      kl.hostname, UID:       kl.hostname, Namespace: api.NamespaceDefault, </ins> } record.Eventf(ref, "", "starting", "Starting kubelet.") }

Discussion:
From kubelet logs: E1117 23:17:17. ] Sleeping: Unable to write event: event "e2e-test-etune-minion-1.c.seventh-circle-487.internal." is invalid: involvedObject.namespace: invalid value '' The kubelet code says: I'll update when I figure out where the record.Event is coming from. The code is:
Event in question is: I1117 23:25:42. ] Event(api.ObjectReference{Kind:"Minion", Namespace:"", Name:"e2e-test-etune-minion-1.c.seventh-circle-487.internal", UID:"e2e-test-etune-minion-1.c.seventh-circle-487.internal", APIVersion:"", ResourceVersion:"", FieldPath:""}): status: '', reason: 'starting' Starting kubelet.
I think the namespace needs to be kubelet. Note that one bad event blocks other good events from getting sent. Probably better to change that.
I'll file a new one for bad event blocking good.
I have a similar issue related to event. When generating event for image, what kind of namespace I should use? Image is not APIObject kubernetes managed, and it could shared crossing several containers even belongs to different pod. Currently I plan to just use default when creating ObjectReference for image related event. If we use kubelet for event related to minion, are we going to make it reserved one?
what events are you planning to add for images? "default" seems like a good enough namespace for minion events for now.
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/api/resource" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/fieldpath" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/fields" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/types"

Discussion:
A "kubectl describe" on a pod ID give a lot of informations about that pod but don't you think it should also print the pod's env var ?