jiebi/CodeConvo huggingface dataset:
Change:
} } <del> // UntilFirstEntryFromZone is a IngestionPred that checks that at least one </del> <ins> // UntilFirstEntryFromLocation is a IngestionPred that checks that at least one </ins> // entry from the log with a given name was ingested. <del> func UntilFirstEntryFromZone(zone string) IngestionPred { </del> <ins> func UntilFirstEntryFromLocation(location string) IngestionPred { </ins> return func(_ string, entries []LogEntry) (bool, error) { for _, e := range entries { <del> if e.Location == zone { </del> <ins> if e.Location == location { </ins> return true, nil } }

Discussion:
This test consistently fails for GKE Regional Clusters: https://k8s- - can you please triage?
/assign
Hey, this was removed from 1.10 because it was never updated. Just want to make sure that this isn't a significant bug.
Yes, this is a significant bug in tests, sorry that it slipped our attention
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/open
Change:
} glog.V(4).Infof("Update endpoints for %v/%v, ready: %d not ready: %d", service.Namespace, service.Name, totalReadyEps, totalNotReadyEps) <del> createEndpoints := len(currentEndpoints.ResourceVersion) == 0 </del> if createEndpoints { // No previous endpoints, create them _, err = e.client.Core().Endpoints(service.Namespace).Create(newEndpoints)

Discussion:
Currently, endpoints objects containing no subsets are decoded by the go client as subsets:[] (when requested individually) or as subsets:null (when requested in a list of endpoints). Because the endpoints controller is fed via a lister/watcher, it gets the subsets:null version fed to it. The subsets computation then returns an empty slice, which fails reflect.DeepEqual, which triggers a write attempt
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
Change:
pod, err = c.Pods(ns).Get(podName) framework.ExpectNoError(err) <del> nodeName := pod.Spec.NodeName By("Trying to apply a random label on the found node.") k := "e2e.inter-pod-affinity.kubernetes.io/zone" v := "china-e2etest" framework.AddOrUpdateLabelOnNode(c, nodeName, k, v) framework.ExpectNodeHasLabel(c, nodeName, k, v) defer framework.RemoveLabelOffNode(c, nodeName, k) By("Trying to launch the pod, now with podAffinity with same Labels.") labelPodName := "with-podaffinity-" + string(uuid.NewUUID()) </del> <ins> By("Trying to launch another pod, now with podAntiAffinity with same Labels.") labelPodName := "with-podantiaffinity-" + string(uuid.NewUUID()) </ins> _, err = c.Pods(ns).Create(&api.Pod{ TypeMeta: unversioned.TypeMeta{ Kind: "Pod",

Discussion:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
Looking into this...
trying to track this flake down. It looks like the pod is launched despite AntiAffinity in . In my local setup I saw the same, but noticed that the new admission controller was not activate.

I have activate it and now get this:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
Should be fixed by
Change:
KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "${KUBE_ROOT}/hack/lib/init.sh" <del> source "${KUBE_ROOT}/hack/lib/util.sh" </del> kube::log::status "Restoring kubernetes godeps"

Discussion:
Didn't see an issue for this. Godep recently updated its version to v80. This broke several builds that directly godep, grabbing latest. /kind bug cc Example https://k8s- Here are some examples where we grab master:
We have helpers to grab godep. We should use them everywhere.
/cc
/assign
Change:
tags = ["automanaged"], deps = [ "//vendor/github.com/pborman/uuid:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/api/errors:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured:go_default_library", "//vendor/k8s.io/apimachinery/pkg/runtime/schema:go_default_library",

Discussion:
Kubernetes version (use ): Kubernetes HEAD Environment: Cloud provider or hardware configuration: linux OS (e.g. from /etc/os-release): Kernel (e.g. ):NAME=Fedora25 What happened: apiserver panic What you expected to happen: No panic How to reproduce it (as minimally and precisely as possible): Testcase is going to be sent as a PR
Fixed by
Change:
namespaces = createNamespaces(f, nodeCount, itArg.podsPerNode) totalPods := itArg.podsPerNode * nodeCount <del> configs = generateRCConfigs(totalPods, itArg.image, itArg.command, c, namespaces) </del> <ins> configs = generateRCConfigs(totalPods, itArg.image, itArg.command, namespaces) </ins> var services []*api.Service // Read the environment variable to see if we want to create services createServices := os.Getenv("CREATE_SERVICES")

Discussion:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
We understand the problem here - I'm working on the fix.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Change:
var timeCh <-chan time.Time doneCh := ctx.Done() <ins> // if immediate is true the condition is // guaranteed to be executed at least once, </ins> // if we haven't requested immediate execution, delay once <del> if !immediate { </del> <ins> if immediate { if ok, err := func() (bool, error) { defer runtime.HandleCrash() return condition(ctx) }(); err != nil || ok { return err } } else { </ins> timeCh = t.C() select { case <-doneCh:

Discussion:
Calling wait.PollUntilContextTimeout with immediate=true does not invoke the passed condition function if context has already been cancelled. wait.PollUntilContextTimeout with immediate=true should invoke the passed condition function at least once even if context has already been cancelled as wait.PollUntilContextCancel documentation says: Note that wait.PollUntilContextTimeout wraps wait.PollUntilContextCancel, so the above should be applied to wait.PollUntilContextTimeout as well. This program panics because context ctx.Err is checked before invoking the passed function. The deprecated wait.PollImmediateWithContext does not have this kind of issue. If wait.PollUntilContextTimeout is the replacement of wait.PollImmediateWithContext, it should exhibit the same behavior. k8s v1.27.2 <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
TestloopConditionUntilContextsemantic also has an issue that immediate and sliding are not tested as expected. immediate and sliding are loop variable, but they are not used in the test. The ones that are used are in testcase struct which are always false.
/assign
ok, it seems this would do it
/assign
/triage accepted
Change:
} } <ins> var debug = false </ins> func dumpEtcdKVOnFailure(t *testing.T, kvClient clientv3.KV) { <del> if t.Failed() { </del> <ins> if t.Failed() && debug { </ins> response, err := kvClient.Get(context.Background(), "/", clientv3.WithPrefix()) if err != nil { t.Fatal(err)

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:
func getFlexDir(c clientset.Interface, node *v1.Node, vendor, driver string) string { volumePluginDir := defaultVolumePluginDir if framework.ProviderIs("gce") { <del> if node == nil && framework.MasterOSDistroIs("gci") { </del> <ins> if node == nil && framework.MasterOSDistroIs("gci", "ubuntu") { </ins> v, err := getMasterVersion(c) if err != nil { framework.Failf("Error getting master version: %v", err)

Discussion:
https://k8s- https://k8s- It passes on COS. /cc
I can look into this, since likely this was introduced because of latest changes I made.
This looks like a timing thing - because I can see message in logs , but I think 5 minutes is not enough for the pod to come up after installing flexvolume.
That's strange, the dummy driver just sets up a tmpfs so it should be fairly quick. I wonder if there's something else blocking pod creation?
the driver is not being installed on kubelet I am doing some more investigating, have my own cluster up.
On ubuntu, we set the flexvolume install dir to --volume-plugin-dir=/home/kubernetes/fl exvolume Small oversight, I'll make a PR shortly
They are still failing, I am having another look e: Same as before, it is not installing on the node. I started my test cluster using (basically...) the same kubetest command sooo allow me to try again. e2: it's a false alarm. The tests are not using a commit with my fix in it yet zzzz
Change:
} if err != nil { klog.V(1).Infof("Failed to bind pod: %v/%v", assumed.Namespace, assumed.Name) <del> if err := sched.SchedulerCache.ForgetPod(assumed); err != nil { klog.Errorf("scheduler cache ForgetPod failed: %v", err) } </del> return }

Discussion:
This is a bug found in The scheduler fails to schedule the pod on the first try due to PV is out of sync. This may happen because the PV/PVC may be modified before the scheduler binder assumes them. However, the scheduler skips the pod update event and never try to scheduler the pod again: This is because when the reserve plugins fails, we didn't try to forget the pod. After the is called, the pod is in the state.
/sig scheduling /sig storage /assign /priority critical-urgent
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig scheduling /sig storage /assign /priority critical-urgent 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:
GetContext:         ctxFn, SelfLinker:         a.group.Linker, ClusterScoped:      true, <del> SelfLinkPathPrefix: gpath.Join(a.prefix, resourcePath, "/"), </del> <ins> SelfLinkPathPrefix: gpath.Join(a.prefix, resourcePath) + "/", </ins> SelfLinkPathSuffix: suffix, }

Discussion:
Bug report Kubernetes version Client Version: version.Info{Major:"1", Minor:"5+", GitVersion:"v1.5.0-beta.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-24T22:35:03Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5+", GitVersion:"v1.5.0-beta.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-24T22:30:23Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"} When you curl the api you get a list of third party resources, however their selflinks are missing a forward slash:
fixed with , you may take a look.
This looks like it affects root scoped resources in general -- both custom ones (e.g. ServiceCatalog brokers, as noted in kubernetes-incubator/service-catalog) and "built-in" ones, like namespaces and nodes:
cc
Change:
ginkgo.By("wait for the deleted pod to be cleaned up from the state file") waitForStateFileCleanedUp() ginkgo.By("the deleted pod has already been deleted from the state file") <ins> }) ginkgo.AfterEach(func() { </ins> setOldKubeletConfig(f, oldCfg) }) }

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: ci-kubernetes-node-kubelet-serial node-kubelet-serial job Which test(s) are failing: Hard to tell, but everything at one point or another. Since when has it been failing: A month or two, by recollection. would indicate several years... ci-kubernetes-node-kubelet-serial | failing_days | 992 Testgrid link: Reason for failure: Hard to tell, some is timeout, but I think timeouts due to test failures. Anything else we need to know: Nothing consistent about the failures that I can tell besides timeouts. This is the only place these serial tests are running.
/sig node
/cc
I will take a look at what happens with the serial lane.
So the kubelet failed to restart because of I think it can be related to the topology manager scope PR, I will dig into the code tomorrow. FYI
It actually looks like it was introduced by: With the same issue reported here: And Alexey has a fix for it here (I haven't reviewed it):
Thanks for the update.
Some of these failures are definitely due to , which is causing tests to fail since pods aren't terminating in time. See e.g.
/assign
Under the latest run, I saw that the kubelet failed to restart because of The problem that one of the topology manager tests failed in the middle and did not remove the state file, I can not guarantee that it a single problem, but let's start from it.
Change:
ginkgo.By("waiting for RC to be modified") eventFound = false <del> ctx, cancel = context.WithTimeout(context.Background(), 30*time.Second) </del> <ins> ctx, cancel = context.WithTimeout(context.Background(), 60*time.Second) </ins> defer cancel() _, err = watchUntilWithoutRetry(ctx, retryWatcher, func(watchEvent watch.Event) (bool, error) { if watchEvent.Type != watch.Modified {

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: - Triage link for more jobs that are affected: Which test(s) are failing: Since when has it been failing: Since October 23 Testgrid link: Reason for failure: Anything else we need to know: Example spyglass link: /sig apps /cc /priority important-soon
/cc missed this in the main body
/assign /triage accepted
/remove-priority important-soon /priority critical-urgent top flake for pull-kubernetes-conformance-kind-ipv6-parallel, 2nd top flake for per /area conformance this is a conformance test /remove-kind failing-test /kind flake this is not failing continuously, but is instead flaking
/assign
I increased the timeout while waiting for available Replicas.
Test grid green since Merge 5 Nov 2020 /cc
Change:
import ( "encoding/json" "errors" <ins> "fmt" </ins> "net/http" "strconv" "strings"

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 using kubectl, authentication fails with the below error For some reason kubectl is adding a lot of s to the start of the SPN - this can be observed in What you expected to happen: Authentication works as in previous versions of Kubectl How to reproduce it (as minimally and precisely as possible): Create a cluster using Azure AD authentication. Authenticate from a client and wait until the token expires. Use Kubectl and have it automatically refresh the token; it will fail due to the extra 'spn:' entries. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: on-premise OS (e.g: ): macOS 10.14.6 Kernel (e.g. ): Darwin Hostname 18.7.0 Darwin Kernel Version 18.7.0: Mon Feb 10 21:08:45 PST 2020; root:xnu-4903.278.28~1/RELEASEX8664 x86_64 Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others:
/sig cli
Kubectl version 1.18.0 Kubernetes version 1.16.6
can you confirm whether your original kubeconfig already has in apiserver-id or not? in the mean time, you may try it can convert your kubeconfig from azure module to exec module and do the token thing outside kubectl
At this point if I remove the tokens and try to reauth i get the error described above. I've tried it both ways with apiserver-id having an initially and not, both lead to the same behavior in the end.
i know what's going on now. will prepare a fix. the root cause is that token's target resource (adal.Token.Resource) needs to have prefix and this prefix gets unexpectedly to as well, which gets written back to kubeconfig. So every time kubectl is run, it adds to apiserver-id
/priority important-soon
I'm seeing this with kubectl 1.17.3 and kubernetes 1.16.7.

It's unclear to me what versions are impacted and in what version it is fixed, since only version 1.18 is mentioned.
This still happens on kubectl 1.16.12 and 1.17.8
This still happens on kubectl v1.18.5
same
can you guys share your kubectl version --client and kubeconfig with me? you can find me on kubernetes slack. the slack user name is same as my github handle.
Version 1.17.6 works fine.
Since I was mistaken thinking was still causing this for me, I figured I would just drop a note for others in case it's helpful. Turns out my problem was actually due to and looks to have been resolved as of the v3.3.0 release.
This issue has now reappeared for me - although not necessarily the same root cause. AKS 1.19.0 Authentication works, but it spams frequently.
Change:
TargetCPUUtilizationPercentage: &cpu, }, } <del> _, errHPA := rc.framework.ClientSet.Autoscaling().HorizontalPodAutoscalers(rc.framework.Namespace.Name).Create(hpa) </del> <ins> hpa, errHPA := rc.framework.ClientSet.Autoscaling().HorizontalPodAutoscalers(rc.framework.Namespace.Name).Create(hpa) </ins> framework.ExpectNoError(errHPA) <ins> return hpa } func DeleteHorizontalPodAutoscaler(rc *ResourceConsumer, autoscalerName string) { rc.framework.ClientSet.Autoscaling().HorizontalPodAutoscalers(rc.framework.Namespace.Name).Delete(autoscalerName, nil) </ins> }

Discussion:
Currently the time it takes for HPA and CA to scale up after load increase is not measured at all, and this can lead to regressions that will be missed. This issue is about adding an e2e test that will prevent such regressions.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
Filip, can you reopen? I cannot do this myself, and this issue is clearly not closed yet.
Thanks Wojtek!
Change:
import ( "errors" "fmt" <ins> "net" </ins> "net/http" "regexp" "strings"

Discussion:
/kind bug What happened: Continuation of . The fix to that bug only takes the first subnetwork in the correct region. However, if the user manual subnets in the region that the cluster exists, it's possible the cloudprovider could choose the wrong subnet. What you expected to happen: If no subnet is specified for a non-legacy network, always take the subnet which was automatically created. /assign /sig network /area platform/gce
Change:
// Waits for the deployment to reach desired state. // Returns an error if minAvailable or maxCreated is broken at any times. func waitForDeploymentStatus(c *client.Client, ns, deploymentName string, desiredUpdatedReplicas, minAvailable, maxCreated int) error { <del> return wait.Poll(poll, 2*time.Minute, func() (bool, error) { </del> <ins> return wait.Poll(poll, 5*time.Minute, func() (bool, error) { </ins> deployment, err := c.Deployments(ns).Get(deploymentName) if err != nil {

Discussion:
cc
Thanks for flagging it! Its not flaky, it is broken as we did not enable deployments for that test suite. Sent to fix that.