jiebi/CodeConvo huggingface dataset:
Change:
return api.PodWaiting, nil } } <del> func (rs *REST) waitForPodRunning(ctx api.Context, pod *api.Pod) (runtime.Object, error) { for { podObj, err := rs.Get(ctx, pod.ID) if err != nil || podObj == nil { return nil, err } podPtr, ok := podObj.(*api.Pod) if !ok { // This should really never happen. return nil, fmt.Errorf("Error %#v is not an api.Pod!", podObj) } switch podPtr.CurrentState.Status { case api.PodRunning, api.PodTerminated: return pod, nil default: time.Sleep(rs.podPollPeriod) } } } </del>

Discussion:
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
I took a quick look, and it seems that we were mostly starved on writing http response: On the other, looking into logs in general it seems that we are lacking CPU, which may be the main reason here...
Also - it's over 3k items in the response. I don't know how big Pod item currently is, but my guess is that it has few kB. This would mean that we were writing around 10MB of response - alone it's not a problem, but if we had a lot of network traffic at that point for some reason (e.g. some relist for some watch) the network might have been a problem.
BTW - I have one idea about it. Note where both of these requests come from: the first one comes from rescheduler the second one comes from test In both cases for scalability, we are using JSONs not protobufs. We should switch both of them to protobufs, and that should significantly improve it: serialized protobufs are much smaller (less data to send) serialization to protobufs is faster (less cpu needed for it). I will send PRs for this.
The remaining thing to do is to bum rescheduler dependency -
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
This is rather unexpected, but I can update the constraints.
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
Did something change in kube-proxy in the last few hours?
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
- we started observing flakes connected to high kube-proxy CPU usage in the last ~2 hours (we didn't have such failure in the last month, and we had 3 in the last two hours). This seems like a regression to me. Are you aware of any changes around it?
The only recent changes should be alpha-gated. Pinging folks who have fingerprints on this in the last month or so.. Do you have any more information on how to trigger it?

Hmm - it seems that last 3 runs of scalability suite failed (and any other in the last few weeks because of that reason). So it seems like a real regression, and the only change from that run is this one: This seems pretty unrelated...
It actually got back to normal after 3 red runs (without any intervention). These might have been some GCE-related issues. I'm going to close this issue. [The first failure, should be fixed after we bumped the version of rescheduler].
Change:
if err != nil { t.Errorf("Test %q failed: GetPVC %q returned error: %v", name, getPVCName(pvc), err) } <del> if !reflect.DeepEqual(cachedPVC, pvc) { </del> <ins> // Cache may be overridden by API object with higher version, compare but ignore resource version. newCachedPVC := cachedPVC.DeepCopy() newCachedPVC.ResourceVersion = pvc.ResourceVersion if !reflect.DeepEqual(newCachedPVC, pvc) { </ins> t.Errorf("Test %q failed: cached PVC check failed [A-expected, B-got]:n%s", name, diff.ObjectDiff(pvc, cachedPVC)) } }

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-bazel-test Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know:
the test failure seems related to the PR that is being tested no other flakes have been observed:
I've run it against latest master locally and it may fail. Not sure why it has low chance to fail in prow job.
- i can recreate it with
/sig testing
Change:
testJSONPathSortOutput(randomPrintOrderTests, t) } <ins> func TestEmptyRange(t *testing.T) { var input = []byte(`{"items":[]}`) var emptyList interface{} err := json.Unmarshal(input, &emptyList) if err != nil { t.Error(err) } tests := []jsonpathTest{ {"empty range", `{range .items[*]}{.metadata.name}{end}`, &emptyList, "", false}, {"empty nested range", `{range .items[*]}{.metadata.name}{":"}{range @.spec.containers[*]}{.name}{","}{end}{"+"}{end}`, &emptyList, "", false}, } testJSONPath(tests, true, t) } </ins> func TestNestedRanges(t *testing.T) { var input = []byte(`{ "items": [

Discussion:
What happened: throws errors if no pods are found in v1.19.3, but returns success with empty response in v1.16.8 What you expected to happen: If there are no pods that return, no error should be thrown as the range should evaluate to "no op". How to reproduce it (as minimally and precisely as possible): Adapt the example from to get the command . Run this when there are pods in default namespace - all is well. Run this when there are no pods in default namespace and you get the error: Anything else we need to know?: This breaks all kinds of code that relies on jsonpath's earlier behaviour. I found an old report () that seems appropriate, but that is long since merged and closed. Environment: Kubernetes version (use ): 1.19.3 Cloud provider or hardware configuration: x86-64 OS (e.g: ): RedHat Enterprise Linux 7.6 (Maipo) Kernel (e.g. ): Install tools: n/a Network plugin and version (if this is a network-related bug): n/a Others: n/a
/sig cli
/cc
/sig api-machinery
/assign cc /triage accepted
Change:
import ( "fmt" "reflect" <ins> "strconv" </ins> "strings" "testing" "github.com/davecgh/go-spew/spew" <ins> "github.com/stretchr/testify/assert" "github.com/stretchr/testify/require" </ins> "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Discussion:
/kind bug What happened: In , there are tests for {Default,}AllowPrivilegeEscalation fields, but those in actually test the AllowPrivilegeEscalation as this is set in the test instead of testing its suggested Default* form, thus being mostly redundant to tests in . On top of that, part of the tests in test a scenario which is not allowed, that being are wrong due to but since this is assigned directly, it was never validated and thus no errors were found. What you expected to happen: There are no redundant or incorrect tests in . Environment: Kubernetes version: master
/sig auth
Resolved by
Change:
"k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/wait" <ins> "k8s.io/kubernetes/pkg/cloudprovider" </ins> ) // requestBackoff if backoff is disabled in cloud provider it

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug /sig azure What happened: When performing a rolling update of my nodes (i.e., cordon, drain, delete VM on Azure side) one after the other the corresponding objects of the deleted VMs are not being deleted from etcd. This affects all patch versions while it is working fine with . What you expected to happen: The objects are removed from etcd when the backing virtual machine does not exist any more. How to reproduce it (as minimally and precisely as possible): Create a Kubernetes cluster with version on Azure, cordon and drain the node and delete the backing VM afterwards. Anything else we need to know?: No. Environment: Kubernetes version (use ): 1.9.X Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): CoreOS Stable 1632.3.0 Others: machine type
It requires some time for controller manager to detect the removed VM on Azure. Could you share the logs of kube-controller-manager?
Hi thank's for taking a a look. Well, sure, it may take some time, however, it's really fast for Kubernetes clusters on Azure with versions prior than and also for clusters on other cloud providers (even with ). I have waited more than 30 minutes, but the "old" objects are still there (which leads to a weird state/view on pods, etc.). I've seen this problem only with Azure . I just reproduced the problem: At this point in time the backing VMs for and are already gone/do not exist any more. The relevant logs of the kube-controller-manager:
Thanks of providing the information. I'm checking whether there is something wrong inside cloud provider
confirmed it's a bug in azure cloud provider
Thank you for investigating. Do you already know whether the fix will be backported or only part of 1.10?
By the way, have you configured backoff with azure cloud provider? what params have you configured?
This is the relevant part of the current cloud provider configuration: Does it look good to you?
There is a problem in backoff logic which results in retrying even the VM has already removed from Azure. With the params you set, the backoff timeout will be about 40 hours. I recommend setting a smaller cloudProviderBackoffDuration (ensure 1) since this is an exponential backoff.
Okay, thank's a lot!
Change:
NodeSelector: map[string]string{labelKey: labelValue}, }) <del> framework.ExpectNoError(e2epod.WaitForPodNameRunningInNamespace(cs, ns, tolerationPodName)) </del> <ins> // check that pod got scheduled. We intentionally DO NOT check that the // pod is running because this will create a race condition with the // kubelet and the scheduler: the scheduler might have scheduled a pod // already when the kubelet does not know about its new taint yet. The // kubelet will then refuse to launch the pod. framework.ExpectNoError(e2epod.WaitForPodNotPending(cs, ns, tolerationPodName)) </ins> deployedPod, err := cs.CoreV1().Pods(ns).Get(tolerationPodName, metav1.GetOptions{}) framework.ExpectNoError(err) framework.ExpectEqual(deployedPod.Spec.NodeName, nodeName)

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: kind serial conformance jobs Which test(s) are failing: The conformance test SchedulerPredicates [Serial] validates that taints-tolerations is respected if matching [Disruptive] [Conformance] Since when has it been failing: The test was promoted in kubernetes/kubernetes passing the kind-ipv6 job but it keeps failing after that in both ipv4 and ipv6 conformance jobs Testgrid link: https://k8s-(IPv6),%20master%20(dev) Reason for failure: Investigating Anything else we need to know: Seems the job in presubmit is not testing Serial conformance :/
/cc
/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. ‍
EDIT: posting GCE results because it is failing there too
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/retitle Failing Test: SchedulerPredicates [Serial] validates that taints-tolerations is respected if matching [Disruptive] [Conformance]
/remove-sig network /sig scheduling /area conformance
I've opened to revert
Change:
srcs = ["gc_admission_test.go"], embed = [":go_default_library"], deps = [ <del> "//pkg/api/legacyscheme:go_default_library", </del> "//pkg/apis/core:go_default_library", <del> "//pkg/client/clientset_generated/internalclientset:go_default_library", </del> "//pkg/kubeapiserver/admission:go_default_library", <del> "//staging/src/k8s.io/apimachinery/pkg/api/meta/testrestmapper:go_default_library", </del> <ins> "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/api/extensions/v1beta1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library",

Discussion:
/kind flake /sig testing /sig auth we are injecting a restMapper into this admisson controller while in its test, the restMapper somehow become empty when we remove internal clientset/informer dependency from it (). now we come up with a walkaround in which we manually init the legacy schema via a dry import so that the built-in resources can be installed. this failing test suggests that the test is not quite correct logically.
/assign Are you up for trying to figure out how to avoid requiring the internal types?
What test does this break? Links?
link here: w/o the dry import, then will fail with output:
sure. will be looking into it
OK, setting priority so that I know this isn't a 1.13 blocker. /priority important-longterm
Change:
}, } } <ins> func setInitializedAnnotation(ss *apps.StatefulSet, value string) { ss.Spec.Template.ObjectMeta.Annotations["pod.alpha.kubernetes.io/initialized"] = value } </ins>

Discussion:
What happened: What you expected to happen: The statefulset should have scaled down to 0. Instead, even after 10 minutes: How to reproduce it (as minimally and precisely as possible): Run the e2e test on a gce cluster running the latest and greatest kubernetes. cc
if the petset has replicas=0 it's not going to do anything
When I a running petset, and set its scale to 0, that seems to work and delete the pets, and we should have a functioning scaler. Am I misunderstanding something? I'm using the same teardown process for the e2e test I linked in the issue as the other tests (), but it times out sometimes after network partition.
yeah is scale in the petset controller noticing deletion timestamp? because the test code you showed doesn't care
As I mentioned yesterday, it isn't even issuing a delete request even after 10 minutes, because the pods continue to be "running". I'll check the controller manager logs today. I suspect it might be the backoff in the rate limited work-queue.
Hmm, the AGE fields on your pets don't make sense if it isn't even issuing a delete?
In the output I pasted above, at the 7 minute mark, it created the new replacement pet-0, after the network partition was healed. Then tried to scale down the StatefulSet and waited 10 minutes for the pods to disappear.
I see a bunch of different failures modes on the bug: 3 08:58:44.475: Failed waiting for pods to enter running: timed out waiting for the condition Failed to scale statefulset to 0 in 10m0s. Remaining pods: [] 3 08:11:30.728: Unexpected error: <nilBasically 3 translates to We should clarify. 1 and 2 both have events like guessing the node controlelr shouldn't be setting timestamp?
Looking into the case 2: The controller manager log goes: So I guess even deletions are being blocked by the health/readiness.
Both issues appear to be due to the testsuite and the way we use the "initialized" annotation in tests. I'll send a PR to fix these shortly. Thanks
Change:
<ins> description: add a testcase description mode: edit args: - configmap namespace: "edit-test" expectedStderr: - edit cancelled, no objects found. expectedExitCode: 1 steps: - type: request expectedMethod: GET expectedPath: /api/v1/namespaces/edit-test/configmaps expectedInput: 0.request resultingStatusCode: 200 resultingOutput: 0.response </ins>

Discussion:
Try running and adding an ingress object, or an empty list, then exit the editor – it will panic like this: I've also tried , and for the sake of experiment tried adding a Pod, then it failed rather gracefully with this message: But when I tried to add a DaemonSet, it paniced. I am not sure how we should fix, perhaps editing of lists isn't something a normal user is expected to do... Let's discuss.
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
So I wanted to test how it would behave if I take an item out of my list, so I've create and ingress object and tried . To my surprise I've found only one ingress object without a list. When I a second object, gave me a list to edit. So I must say that flattening of the list in case there is only one object was a bit surprising. Now that I have a list of two items, I've decided to try deleting one by removing it from the list, and it turns that's not possible.
It feels like the problem is complicated, and I'd rather see disallowed unless users passed a name of a specific resource. If we belive some folks rely on to work when there is only one resource to edit, maybe we can keep that... If we cannot disallow this, I'd rather see it fixed in a way where removing items results in deletion and editing a single item list is actually about editing a list. At the very least, of course, we should fix the panic, but I still want to hear what people think about this before I open a PR (presumably fixing that panic should be trivial).
I'm working on this. Already submitted a PR in . PTAL.
I think at the very beginning, at least v1.5.0 the logic is already like this, I'm not sure why this bothering you I use this lot of time, I'd prefer keep it.

also cc
I don't think edit should open with an empty list. should open a list if there are multiple items, a single item if there is only one, and error if there are none of that type. should open a single item if it is found, and error if it is not found
that sounds good to me. I was just a bit surprised, that's all.
Change:
"github.com/onsi/gomega" ) <del> // TODO(random-liu): Get this automatically from kubelet flag. var kubeletAddress = flag.String("kubelet-address", "http://127.0.0.1:10255", "Host and port of the kubelet") </del> var startServices = flag.Bool("start-services", true, "If true, start local node services") var stopServices = flag.Bool("stop-services", true, "If true, stop local node services after running tests") var busyboxImage = imageutils.GetE2EImage(imageutils.BusyBox)

Discussion:
There is a todo in the node e2e test suite to obtain the kubelet address from the kubelet config The kubelet address is used in The kubelet flag is itself deprecated, , so we could get it from the kubelet config. /help wanted /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : There is a todo in the node e2e test suite to obtain the kubelet address from the kubelet config --address 0.0.0.0 The IP address for the Kubelet to serve on (set to 0.0.0.0 for all IPv4 interfaces and for all IPv6 interfaces) (default 0.0.0.0) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See for more information.) , so we could get it from the kubelet config. /good-first-issue </details
/sig node
can I give it a try?
/assign knabben
Change:
Eventually(terminateContainer.Present, retryTimeout, pollInterval).Should(BeFalse()) } }) <ins> It("should report termination message if TerminationMessagePath is set [Conformance]", func() { name := "termination-message-container" terminationMessage := "DONE" terminationMessagePath := "/dev/termination-log" c := ConformanceContainer{ Container: api.Container{ Image:   ImageRegistry[busyBoxImage], Name:    name, Command: []string{"/bin/sh", "-c"}, Args:    []string{fmt.Sprintf("/bin/echo -n %s > %s", terminationMessage, terminationMessagePath)}, TerminationMessagePath: terminationMessagePath, }, Client:        f.Client, RestartPolicy: api.RestartPolicyNever, NodeName:      *nodeName, Namespace:     f.Namespace.Name, } By("create the container") Expect(c.Create()).To(Succeed()) defer c.Delete() By("wait for the container to succeed") Eventually(c.GetPhase, retryTimeout, pollInterval).Should(Equal(api.PodSucceeded)) By("get the container status") status, err := c.GetStatus() Expect(err).NotTo(HaveOccurred()) By("the container should be terminated") Expect(GetContainerState(status.State)).To(Equal(ContainerStateTerminated)) By("the termination message should be set") Expect(status.State.Terminated.Message).Should(Equal(terminationMessage)) By("delete the container") Expect(c.Delete()).To(Succeed()) }) </ins> }) Context("when running a container with a new image", func() {

Discussion:
When working on , I found that doesn't work now. Now we rely on in container inspect result to map to host directory path (See ). However, the in inspect result has been deprecated from docker 1.8.x (See ). Even though there is still field in , it is empty in fact. The new field in is a set instead of map. (See ) We should use in container inspect result or in instead.
Change:
"k8s.io/kubernetes/plugin/pkg/auth/authenticator/token/bootstrap" ) <ins> const etcdRetryLimit = 60 const etcdRetryInterval = 1 * time.Second </ins> // NewAPIServerCommand creates a *cobra.Command object with default parameters func NewAPIServerCommand() *cobra.Command { s := options.NewServerRunOptions()

Discussion:
See: This code should make several attempts before ing. Alternatively, we could consider not listening for connections until this code has succeeded.
Feel free to correct me if I'm wrong on any of this since I've never looked at kubernetes code base before. The code for the and the both appear to make multiple attempts before returning an error which leads to a Fatal.
, I think we had waited for to start at . Do we need to wait more or make it configurable?
I would like to work on this if nobody else is.
No need to ask for permission! Just say here that you're working on it, that should be sufficient to prevent duplicate work. :)
Can I have a go at this?
I have a nearly completed solution for this already. Just working on testing/test cases. WIll hopefully sumbit a PR shortly.
Ok.
I wondered why we care about this. After all, kubelet restarts failing pods. For posterity, after talking with the reason is that the apiserver may fail so fast that the kubelet begins to back off on restarts of a failing pod. That backoff may be too aggressive. (Maybe it causes spurious alerts, or maybe it allows too much downtime.) So, let's fix the apiserver. That's fine, but clearly we're not the only user that might encounter this. You may be running a server you don't want to (or can't) modify, and you might wish you could tweak the kubelet's backoff heuristics for your pod. Alternately, maybe the kubelet could choose not to enter the backoff if apiserver exited with a different code. anything like this already in place?
That's a wonderful explanation that hadn't occurred to me. If there isn't a feature request for this already I'll work on something and reference this issue.
AFAIK, the backoff mechanism is there to protect kubelet from being overwhelmed by failed user containers. Trusting the containers with returning a specific exit code sounds like a big "no" to me. Making this configurable per pod might be ok, but it's still not good in general to allow aggressive restarts.
The referred PR () only fixes the issue for kube-apiserver. We still need a generic fix in genericapiserver (Ref ).
Change:
id: monitoring-grafana port: 80 containerPort: 80 <ins> labels: name: grafana kubernetes.io/cluster-service: "true" </ins> selector: name: influxGrafana

Discussion:
As per we should add a common label to all of our add-on pods: DNS, logging, monitoring, etc. The proposal is to add "": "true" for now.
FWIW "true" has to be quoted in YAML
Can you close this one once it's completed.