jiebi/CodeConvo huggingface dataset:
Change:
if len(elbPolicy.VIPs) == 0 || elbPolicy.VIPs[0] != vip { continue } <ins> } else if len(elbPolicy.VIPs) != 0 { continue </ins> } LogJson(plist, "Found existing Hns loadbalancer policy resource", 1) return &loadBalancerInfo{

Discussion:
What happened: I created a service where the was the same as the , and having done so, then the was not accessible externally on the Windows node where the pod was running (it was, however, accessible on the Linux master). When I changed either the or the so that they were different then the service was accessible on the Windows node. What you expected to happen: I expect services to work when the and the are the same value. How to reproduce it (as minimally and precisely as possible): Here's the file that I used: Then, in a web browser on my desktop machine, I visited the on both the Linux master's IP address, and then in a different tab, using the again, the IP address of the Windows worker node where that pod was scheduled. It only worked using the IP address of the Linux master. The tab using the Windows worker node's IP address did not load. Then, I changed either the or the so that they were different values, and when they were different, it worked using the of both the Linux master's IP address and the IP address of the Windows worker node where that pod was scheduled. Anything else we need to know?: On-premise install of k8s The Windows nodes all have the following feature gates enabled: WinOverlay WindowsGMSA Linux master: OS (e.g. ): Windows worker: If you need any more information then please let me know.
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
Can you take a look?
Change:
"fmt" "time" <ins> influxdb "github.com/influxdb/influxdb/client" </ins> . "github.com/onsi/ginkgo" . "github.com/onsi/gomega" "k8s.io/kubernetes/pkg/api"

Discussion:
Jenkins project: kubernetes-e2e-gce-autoscaling failed last couple of runs: Initial Resources [Skipped][Autoscaling Suite] should set initial resources based on historical data Expected <int64: to be ~ <int:
couple failing instances:
Re-opening. This flaked again:
status?
The test is disabled and there is no plan to enable it within next few weeks, so closing the issue and I'll back to it some time in the future.
Change:
"3": []algorithm.PredicateFailureReason{algorithmpredicates.ErrNodeUnderDiskPressure}, }, } <del> if strings.Contains(error.Error(), NoNodeAvailableMsg) { if strings.Contains(error.Error(), "NodeUnderDiskPressure (2)") && strings.Contains(error.Error(), "NodeUnderMemoryPressure (1)") { </del> <ins> if strings.Contains(err.Error(), NoNodeAvailableMsg) { if strings.Contains(err.Error(), "NodeUnderDiskPressure (2)") && strings.Contains(err.Error(), "NodeUnderMemoryPressure (1)") { </ins> return } } <del> t.Errorf("Error message doesn't have all the information content: [" + error.Error() + "]") </del> <ins> t.Errorf("Error message doesn't have all the information content: [" + err.Error() + "]") </ins> } // The point of this test is to show that you:

Discussion:
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:
utilerrors "k8s.io/kubernetes/pkg/util/errors" utilexec "k8s.io/kubernetes/pkg/util/exec" utiliptables "k8s.io/kubernetes/pkg/util/iptables" <ins> utilnet "k8s.io/kubernetes/pkg/util/net" </ins> utilsets "k8s.io/kubernetes/pkg/util/sets" utilsysctl "k8s.io/kubernetes/pkg/util/sysctl"

Discussion:
This is at least partially responsible for - some tests can't run when dns is down. Logs from just before the crash: It got killed because Kubelet decided to kill it (readiness probe failed): It started happening quite recently - I'm trying to locate a build which caused this. Repro: run "Kubelet should not restart containers across restart" test - it caused this behavior for me multiple times today. cc - I applied the P0/v1.3 label/milestone, as I think it should be a blocker. Feel free to decrease the priority if you disagree
gce-serial 1511 seems to be the first one with this problem.
Or 1510 - hard to tell, as it was a broken run. There's no PR around that looks too suspicious though:/
I locally reverted and it seems that DNS is no longer failing. Sadly I have to run to catch a train, but maybe someone can pick it up here ?
Taking a look now. The PR should be unrelated...I am checking to see if the Federation DNS changes went in yet. Add nethealth container to prepull manifest
I search the restart counts for jobs from 1510-latest and gce-serial Job 1540 is the first one to show a non-zero kubedns restart count. If there is a commit responsible, it would be between 1539 and 1540 (June 21 7 AM -11 AM) 1539 end of run 1540 end of run Latest
The kubedns:1.3 container hasn't been updated since (Sat, 04 Jun 2016 03:29:37.847 GMT). GET
cc The kubedns container code is from June 04th. Dawn suggested that its networking issues that are causing kubedns container to fail its readiness check. I will need to add logic to print kubedns container logs during e2e tests, I am trying to search for any logs that might help, otherwise I will have to debug the next run live.
As reported, a simple kubelet restart triggers this issue - it looks like 10.0.0.1 is unreachable from the kubedns container.

The kubedns container blocks indefinitely waiting for a connection to the kubernetes service at 10.0.0.1 before setting up the healthz handlers - the readiness probe will fail until kubedns successfully connects to the API server.
- you can try reverting and running it again - it worked for me for some reason (it might be by accident though)
I think the root cause is that cbr0 doesn't have an IP address assigned after kubelet restart - all the pods running behind cbr0 are isolated from the network. Not only kube-dns, but after my kubelet restart, the other addon pods are also stuck in a crash loop.
This sounds like a blocker even more now.
Looks like a regression. I am investigating.
Found the root cause. There is a subnet ip mismatch. vs . Hence kubenet thinks they are different and clears the address. Will submit a fix soon.
i found coredns status is CrashLoopBackOff and i check the logs : i got tips from so i restart my docker , i check the logs , there is no error in logs again
Change:
oldCfg, err := getCurrentKubeletConfig() framework.ExpectNoError(err) newCfg := oldCfg.DeepCopy() <ins> if newCfg.FeatureGates == nil { newCfg.FeatureGates = make(map[string]bool) } </ins> // Enable CPU Manager using feature gate. newCfg.FeatureGates[string(features.CPUManager)] = true

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: Received panic when I make a e2e-node test: What you expected to happen: Do not panic. How to reproduce it (as minimally and precisely as possible): Execute test locally like: 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:
/sig testing
/sig node
Change:
API Server using the current Aggregator [Conformance]' description: Ensure that the sample-apiserver code from 1.17 and compiled against 1.17 will work on the current Aggregator/API-Server. <del> release: v1.17 </del> <ins> release: v1.17, v1.21 </ins> file: test/e2e/apimachinery/aggregator.go - testname: Custom Resource Definition Conversion Webhook, convert mixed version list codename: '[sig-api-machinery] CustomResourceConversionWebhook [Privileged:ClusterAdmin]

Discussion:
[x] test pr : kuberenetes/kubernetes# [x] two weeks soak start date : testgrid-link [x] two weeks soak end date : [x] test promotion pr : kubernetes/kubernetes#? According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. With this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Addressing the following endpoints in this document; Using the current e2e test as a template, create an APIService for Using the REST client, read the APIService status (readApiregistrationV1APIServiceStatus) and confirm the value of . Using the REST client, patch the APIService (patchApiregistrationV1APIService) before confirming that it has been updated. Using the REST client, list all APIServices in the cluster (listApiregistrationV1APIService) before confirming that can be found. Clean up APIService resources used by the test. Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. This query shows the endpoints hit within a short period of running the e2e test example endpoint | useragent ---------------------------------------|
createApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 deleteApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 listApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 patchApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 readApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 readApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator2 (6 rows) Based on the initial APIsnoop query and the results listed above there are three new endpoints hit.

If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
Change:
} } <ins> type testNamespaceGetter struct { ns *corev1.Namespace } func (t *testNamespaceGetter) GetNamespace(ctx context.Context, name string) (*corev1.Namespace, error) { return t.ns, nil } </ins> type testPodLister struct { called bool pods   []*corev1.Pod

Discussion:
Tasks: [ ] status updates don't produce warnings [ ] spec updates don't block on enforce failures [ ] spec updates produce correct user-visible warnings
I want to do this and consult at slack.
/assign
Change:
gvr:  myCRDV1Beta1, name: "sentinel-resource", patch: map[string]interface{}{ <del> // Just keep using different values sentinelName: fmt.Sprintf("invalid %v %v", uuidString, counter), </del> <ins> sentinelName: fmt.Sprintf("invalid-%d", counter), </ins> }}.Do(ctx) if err == nil {

Discussion:
integration TestRatchetingFunctionality/Enum TestRatchetingFunctionality/MinPropertiesMaxProperties TestRatchetingFunctionality/CELOptionalOldSelf TestRatchetingFunctionality/ TestRatchetingFunctionality/ since 3/8 No response /sig api-machinery
/assign /triage accepted
Change:
} } <del> // TODO(#113606): connect this with the incoming context parameter, which comes from the pod worker. // Currently, using that context causes test failures. To remove this todoCtx, any wait.Interrupted // errors need to be filtered from result and bypass the reasonCache - cancelling the context for // SyncPod is a known and deliberate error, not a generic error. todoCtx := context.TODO() </del> <ins> // TODO(#113606): use cancellation from the incoming context parameter, which comes from the pod worker. // Currently, using cancellation from that context causes test failures. To remove this WithoutCancel, // any wait.Interrupted errors need to be filtered from result and bypass the reasonCache - cancelling // the context for SyncPod is a known and deliberate error, not a generic error. // Use WithoutCancel instead of a new context.TODO() to propagate trace context </ins> // Call the container runtime's SyncPod callback <del> result := kl.containerRuntime.SyncPod(todoCtx, pod, podStatus, pullSecrets, kl.backOff) </del> <ins> sctx := context.WithoutCancel(ctx) result := kl.containerRuntime.SyncPod(sctx, pod, podStatus, pullSecrets, kl.backOff) </ins> kl.reasonCache.Update(pod.UID, result) if err := result.Error(); err != nil { // Do not return error if the only failures were pods in backoff

Discussion:
spans are not being parented to other spans - propagation of context seems broken. More context: spans should be parented to other spans enable kubelet tracing at v1.28 and hook up a tracing backend. No response <detailsv1.28 at least </details<detailsNot sure this matters. </details<details</details<details</details<details</details<details</details
/sig instrumentation /assign
/triage accepted
!
repro steps:
/assign Thanks for helping to look into this! Feel free to post the findings here you shared with me on slack
GitHub didn't allow me to assign the following users: fatsheep9146. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
Thanks! I will post this ASAP
The broken issue is due to the pr , which try to propagate context brought by pod worker to syncPod function in order to let the syncPod can be interrupted in time by other asynchronous routines, for example eviction. But in the line we did not pass the context which contain the parent span and trace into function, so the trace is broken. So I want to fix this by passing the into , which is also desired in comment But passing the ctx into syncPod may have something other to do as described in comments, so I tried to fix as comments advised.
cc
Change:
Replicas: replicas, Template: api.PodTemplateSpec{ ObjectMeta: api.ObjectMeta{ <del> Labels: labels, Annotations: map[string]string{ "pod.alpha.kubernetes.io/initialized": "false", }, </del> <ins> Labels:      labels, Annotations: map[string]string{}, </ins> }, Spec: api.PodSpec{ Containers: []api.Container{

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:
// No credentials provided, useInstanceMetadata should be enabled for Kubelet. // TODO(feiskyer): print different error message for Kubelet and controller-manager, as they're // requiring different credential settings. <del> if !config.UseInstanceMetadata && az.Config.CloudConfigType == cloudConfigTypeFile { </del> <ins> if !config.UseInstanceMetadata && config.CloudConfigType == cloudConfigTypeFile { </ins> return fmt.Errorf("useInstanceMetadata must be enabled without Azure credentials") }

Discussion:
What happened: While trying to setup a outside of the cluster, I had a panic as follow: What you expected to happen: Produce an error message as my configuration lacks some options. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.18.4 Cloud provider or hardware configuration: Azure Others: --cloud-config= The panics come from because we exit as we're not in this case as the is just defaulted-initialised by the caller to here: and effectively assigned afterwards
/sig cloud-provider
/area provider/azure
cc
thanks for reporting the issue and filing the PR to fix it
Change:
"-j", "ACCEPT", ) <ins> // Install the kubernetes-specific postrouting rules. We use a whole chain for // this so that it is easier to flush and change, for example if the mark // value should ever change. // NB: THIS MUST MATCH the corresponding code in the kubelet writeLine(proxier.natRules, []string{ "-A", string(kubePostroutingChain), "-m", "mark", "!", "--mark", fmt.Sprintf("%s/%s", proxier.masqueradeMark, proxier.masqueradeMark), "-j", "RETURN", }...) // Clear the mark to avoid re-masquerading if the packet re-traverses the network stack. writeLine(proxier.natRules, []string{ "-A", string(kubePostroutingChain), // XOR proxier.masqueradeMark to unset it "-j", "MARK", "--xor-mark", proxier.masqueradeMark, }...) masqRule := []string{ "-A", string(kubePostroutingChain), "-m", "comment", "--comment", `"kubernetes service traffic requiring SNAT"`, "-j", "MASQUERADE", } if proxier.iptables.HasRandomFully() { masqRule = append(masqRule, "--random-fully") } writeLine(proxier.natRules, masqRule...) // Install the kubernetes-specific masquerade mark rule. We use a whole chain for // this so that it is easier to flush and change, for example if the mark // value should ever change. writeLine(proxier.natRules, []string{ "-A", string(KubeMarkMasqChain), "-j", "MARK", "--or-mark", proxier.masqueradeMark, }...) </ins> // Write the end-of-table markers. writeLine(proxier.filterRules, "COMMIT") writeLine(proxier.natRules, "COMMIT")

Discussion:
Which jobs are failing: pull-kubernetes-e2e-gci-gce-ipvs Which test(s) are failing: Not all of these fail on every run: [sig-network] Networking Granular Checks: Services should function for endpoint-Service: http [sig-network] Services should allow pods to hairpin back to themselves through services [sig-storage] Flexvolumes should be mountable when non-attachable [sig-network] Networking Granular Checks: Services should function for endpoint-Service: udp [sig-network] Services should have session affinity timeout work for service with type clusterIP [LinuxOnly] [Conformance] [sig-network] Services should allow pods to hairpin back to themselves through services Since when has it been failing: Looking through job history, it looks like the last time any runs passed was on May 2. Testgrid link: N/A since testgrid filtered tests based on [sig-network] Anything else we need to know: This was discovered by in , it also appears to be affecting other PRs. /cc /sig network
This seems related to , but if I'm interpreting test results correctly pull-kubernetes-e2e-gci-gce-ipvs never stopped failing.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign I'll try to fix those cases
May I ask why do you think this is related to ? Seems like first two flexvolumes related cases failed, then after some commit, service related cases start failing.
let me handle the services tests, I think I know the problem, will try to submit a fix today. Do you know what happen with the storage ones?
/assign I just submitted a PR to fix the failing tests
Thanks, seems like all cases fixed.
Change:
etcd-servers: http://<master-private-ip>:4001 metadata: "role=node" flannel: <del> interface: eth1 </del> etcd_endpoints: http://<master-private-ip>:4001 units: - name: etcd.service

Discussion:
Tried to run through this guide: On VMware, there is no eth1, so the flannel configuration dies. Once you get past that, there is also an issue where etcdctl doesn't properly update the flannel network settings because the etcd server isn't set to the master.
Change:
"containers": [{ "name": "php-redis", "image": "brendanburns/php-redis", <ins> "cpu": 100, </ins> "memory": 10000000, "ports": [{"containerPort": 80, "hostPort": 8000}] }]

Discussion:
HPA tests are currently failing in gke-large cluster suite: I did some debugging and the problem seems to be related to pod-nanny. Looking into logs from the last run: was first scheduled on the large node dedicated to it pod-nany updated heapster deployment then heapster was scheduled on the normal node (when it actually shouldn't fit) that point it was never updated by the pod nanny. that point, heapster started crashlooping (OOMing) [which in fact was expected in too small machine] So it's pretty clear that that pod-nanny changed the amount of resources to something smaller, which in fact it shouldn't.