jiebi/CodeConvo huggingface dataset:
Code change:
Seen in the KIND e2e test: a) maybe we shouldn't log this more than 1x per second or something? b) maybe the error could make it clearer that the problem is the user's data? c) maybe we could fix the test triggering this? /sig api-machinery /wg apply Logs that I saw this in:
The 'duplicate entries for key' error came from validatingObjectWalker#visitListItems.
/assign
Yeah, they have multiple environment variables with the same name. I don't think that should be an error though ...
/cc
At the same time, it's not really useful to have multiple times the same variable and is probably a recipe for trouble.
It's definitely user error. Spamming apiserver logs about it doesn't help things, though.
I don't want to hide it, it's really not supposed to happen :-) it's not really user-data though. The fact that the error triggers here rather than in the actual validation means that there is a discrepancy between our validation and the regular validation. That's probably a problem that we have to fix. In that specific example, we can see that Kubernetes allows multiple environment variable with the same name, while we have assumed that it's not OK. It's a very legitimate error and we have to think about it to fix it. I think the test is relevant, and people out there are doing that. We could consider doing ratcheting if we want to stop allowing multiple variables, but I don't think that's how we want to fix that problem.
For history: should fix that.
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
We've definitely improved that, maybe let's close it for now.
/reopen We still see this happening. Kube users get nervous, I would too. Please fix the root cause.
Reopened this issue. <detailsIn response to : /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

Related discussion:
text: // trigger a new deployment framework.Logf("%02d: triggering a new rollout for deployment %q", i, deployment.Name) deployment, err = e2edeployment.UpdateDeploymentWithRetries(c, ns, deployment.Name, func(update *appsv1.Deployment) { <del> newEnv := v1.EnvVar{Name: "A", Value: fmt.Sprintf("%d", i)} </del> <ins> newEnv := v1.EnvVar{Name: fmt.Sprintf("A%d", i), Value: fmt.Sprintf("%d", i)} </ins> update.Spec.Template.Spec.Containers[0].Env = append(update.Spec.Template.Spec.Containers[0].Env, newEnv) randomScale(update, i) })
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: when i installed k8s using kubeadm and my custom config like then output is It is a bug that the default value(Node,RBAC) is entered but a warning message is displayed. A function must be to compare two string slices. What you expected to happen: If the default value and custom value are the same, no warning message should be displayed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 17.3 Install tools: kubeadm /area kubeadm /feature bug /sig cluster-lifecycle
/lifecycle active

Related discussion:
text: // only return the user provided mode if at least one was valid if len(mode) > 0 { <del> klog.Warningf("the default kube-apiserver authorization-mode is %q; using %q", strings.Join(defaultMode, ","), strings.Join(mode, ","), ) </del> <ins> if !compareAuthzModes(defaultMode, mode) { klog.Warningf("the default kube-apiserver authorization-mode is %q; using %q", strings.Join(defaultMode, ","), strings.Join(mode, ","), ) } </ins> return strings.Join(mode, ",") } } return strings.Join(defaultMode, ",") } <ins> // compareAuthzModes compares two given authz modes and returns false if they do not match func compareAuthzModes(a, b []string) bool { if len(a) != len(b) { return false } for i, m := range a { if m != b[i] { return false } } return true } </ins> func isValidAuthzMode(authzMode string) bool { allModes := []string{ kubeadmconstants.ModeNode,
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: when i installed k8s using kubeadm and my custom config like then output is It is a bug that the default value(Node,RBAC) is entered but a warning message is displayed. A function must be to compare two string slices. What you expected to happen: If the default value and custom value are the same, no warning message should be displayed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 17.3 Install tools: kubeadm /area kubeadm /feature bug /sig cluster-lifecycle
/lifecycle active

Related discussion:
text: }) } } <ins> func TestCompareAuthzModes(t *testing.T) { var tests = []struct { name   string modesA []string modesB []string equal  bool }{ { name:   "modes match", modesA: []string{"a", "b", "c"}, modesB: []string{"a", "b", "c"}, equal:  true, }, { name:   "modes order does not match", modesA: []string{"a", "c", "b"}, modesB: []string{"a", "b", "c"}, }, { name:   "modes do not match; A has less modes", modesA: []string{"a", "b"}, modesB: []string{"a", "b", "c"}, }, { name:   "modes do not match; B has less modes", modesA: []string{"a", "b", "c"}, modesB: []string{"a", "b"}, }, } for _, rt := range tests { t.Run(rt.name, func(t *testing.T) { equal := compareAuthzModes(rt.modesA, rt.modesB) if equal != rt.equal { t.Errorf("failed compareAuthzModes:nexpected:n%vnsaw:n%v", rt.equal, equal) } }) } } </ins>
Code change:
Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestStressingCascadingDeletion Testgrid link: Reason for failure: Maybe related: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig api-machinery
I'm seeing lots of these.
post-submit failures (all of these are flakes):
first failure seen in postsubmit is , part of ... preceeding many runs looked clean
I verified the delete options as seen by the server are identical before and after , so I don't think it is a functional change related to that PR
notably, many other tests in this suite started flaking on 3/7 and after ()
figured it out, dropped the detection of empty deletion options which would trigger the test to wait for all pods to be observed by the GC controller

Related discussion:
text: } orphan := false switch { <ins> case options.OrphanDependents == nil && options.PropagationPolicy == nil && len(initialFinalizers) == 0: // if there are no deletion options, the default policy for replication controllers is orphan orphan = true </ins> case options.OrphanDependents != nil: // if the deletion options explicitly specify whether to orphan, that controls orphan = *options.OrphanDependents
Code change:
<!-- 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 --Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestSubresourcePatch Testgrid link: Reason for failure: Unknown. A diff with the original object would be helpful. Anything else we need to know: /sig api-machinery
OK Trying to reproduce, see what's going on.
Clearly this is because SSA is updating the tracked entry's time. It happens when the two request don't happen in the same second. Having a between the two requests makes this into a definitive error.
/wg apply
This seems to be because of . A repeated patch like will always trigger a new managedFields entry to be created, since it's always going to change the object (status or spec will be wiped depending on the endpoint), so the patch will always cause the object to change, which will always cause the entry to be created.
/assign
/assign
/assign
Still seeing this, bumped into it over in
deflake in while the underlying issue is being worked on in

Related discussion:
text: t.Fatalf("metadata.resourceVersion not found") } <del> // this call waits for the resourceVersion to be reached in the cache before returning. // We need to do this because the patch gets its initial object from the storage, and the cache serves that. // If it is out of date, then our initial patch is applied to an old resource version, which conflicts // and then the updated object shows a conflicting diff, which permanently fails the patch. // This gives expected stability in the patch without retrying on an known number of conflicts below in the test. // See https://issue.k8s.io/42644 _, err = noxuResourceClient.Get(context.TODO(), "foo", metav1.GetOptions{ResourceVersion: patchedNoxuInstance.GetResourceVersion()}) if err != nil { t.Fatalf("unexpected error: %v", err) } </del> // Scale.Spec.Replicas = 7 but Scale.Status.Replicas should remain 0 gottenScale, err := scaleClient.Scales("not-the-default").Get(context.TODO(), groupResource, "foo", metav1.GetOptions{}) if err != nil {
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: When creating a new cluster using , panics with SIGSEGV on first run: Note that after the crash the pod restarts, and the second run is successful: and everything seems to be working as expected. What you expected to happen: starts successfully the first time. How to reproduce it (as minimally and precisely as possible): Create a new cluster using , with in mode. Anything else we need to know?: Environment: Kubernetes version (use ): 1.18.0 Cloud provider or hardware configuration: Hetzner VPS OS (e.g: ): Ubuntu 18.04.4 LTS Kernel (e.g. ): 5.3.0-45-generic (Ubuntu's default HWE kernel) Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others: using CRI and mode Please let me know if you need any additional information.
/sig network
/assign
According to the panic output, the crashed code is For some reason, might be nil, we should always check it before using.
Do we understand WHY it is nil?
One more thing I've noticed while fiddling with the cluster is that if I remove the node and re-join it, starts just fine, so I'm guessing it has to do with the initial state of the server / ipvs.
That would be my guess too. And that sort of race is worth fixing :)
do you see anything in the logs in the form: ??
I think somewhere here we're failing to initialize the IPVS interface. We probably shouldn't ignore the error from also :grimacing:
Nope, I posted the (full) logs in the issue description.
Thanks, will look into it deeper
do you happen to have a start up script that loads the necessary IPVS modules or is it preloaded on your nodes? Wondering if there could be a race between when the modules get loaded and when proxy starts up. Either way we should log the error ().
Neither, but if you give me the module list I can try to load them before creating the cluster to see if I still get the panic.
For kernel <4.19: For = 4.19:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I can confirm that, if I explicitly preload the modules, starts successfully the first time.
According to this log , we can confirm second check success, missing modules loaded after first failed check. Because missing modules loaded but not put to

Related discussion:
text: } ipvsModules := utilipvs.GetRequiredIPVSModules(kernelVersion) <del> var bmods []string </del> <ins> var bmods, lmods []string </ins> // Find out loaded kernel modules. If this is a full static kernel it will try to verify if the module is compiled using /boot/config-KERNELVERSION modulesFile, err := os.Open("/proc/modules")
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: When creating a new cluster using , panics with SIGSEGV on first run: Note that after the crash the pod restarts, and the second run is successful: and everything seems to be working as expected. What you expected to happen: starts successfully the first time. How to reproduce it (as minimally and precisely as possible): Create a new cluster using , with in mode. Anything else we need to know?: Environment: Kubernetes version (use ): 1.18.0 Cloud provider or hardware configuration: Hetzner VPS OS (e.g: ): Ubuntu 18.04.4 LTS Kernel (e.g. ): 5.3.0-45-generic (Ubuntu's default HWE kernel) Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others: using CRI and mode Please let me know if you need any additional information.
/sig network
/assign
According to the panic output, the crashed code is For some reason, might be nil, we should always check it before using.
Do we understand WHY it is nil?
One more thing I've noticed while fiddling with the cluster is that if I remove the node and re-join it, starts just fine, so I'm guessing it has to do with the initial state of the server / ipvs.
That would be my guess too. And that sort of race is worth fixing :)
do you see anything in the logs in the form: ??
I think somewhere here we're failing to initialize the IPVS interface. We probably shouldn't ignore the error from also :grimacing:
Nope, I posted the (full) logs in the issue description.
Thanks, will look into it deeper
do you happen to have a start up script that loads the necessary IPVS modules or is it preloaded on your nodes? Wondering if there could be a race between when the modules get loaded and when proxy starts up. Either way we should log the error ().
Neither, but if you give me the module list I can try to load them before creating the cluster to see if I still get the panic.
For kernel <4.19: For = 4.19:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I can confirm that, if I explicitly preload the modules, starts successfully the first time.
According to this log , we can confirm second check success, missing modules loaded after first failed check. Because missing modules loaded but not put to

Related discussion:
text: if err != nil { klog.Warningf("Failed to load kernel module %v with modprobe. "+ "You can ignore this message when kube-proxy is running inside container without mounting /lib/modules", module) <ins> } else { lmods = append(lmods, module) </ins> } } } <del> return append(mods, bmods...), nil </del> <ins> mods = append(mods, bmods...) mods = append(mods, lmods...) return mods, nil </ins> } // getFirstColumn reads all the content from r into memory and return a
Code change:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery

Related discussion:
text: if pod == nil { return fmt.Errorf("pod is missing, skipping (%s/%s)", addr.TargetRef.Namespace, addr.TargetRef.Name) } <del> if pod.Status.PodIPs[0].IP != addr.IP { return fmt.Errorf("pod ip doesn't match endpoint ip, skipping: %s vs %s (%s/%s)", pod.Status.PodIPs[0].IP, addr.IP, addr.TargetRef.Namespace, addr.TargetRef.Name) </del> <ins> for _, podIP := range pod.Status.PodIPs { if podIP.IP == addr.IP { return nil } </ins> } <del> return nil </del> <ins> return fmt.Errorf("pod ip(s) doesn't match endpoint ip, skipping: %v vs %s (%s/%s)", pod.Status.PodIPs, addr.IP, addr.TargetRef.Namespace, addr.TargetRef.Name) </ins> } // This is O(N), but we expect haystack to be small;
Code change:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery

Related discussion:
text: Ports:     []api.EndpointPort{{Name: "", Port: 80}, {Name: "p", Port: 93}}, }}, }, <ins> { ObjectMeta: metav1.ObjectMeta{ Name:      "foo-second-ip", Namespace: metav1.NamespaceDefault, }, Subsets: []api.EndpointSubset{{ Addresses: []api.EndpointAddress{{IP: "2001:db7::", TargetRef: &api.ObjectReference{Name: "foo", Namespace: metav1.NamespaceDefault}}}, Ports:     []api.EndpointPort{{Name: "", Port: 80}, {Name: "p", Port: 93}}, }}, }, </ins> }, } pods := &api.PodList{
Code change:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery

Related discussion:
text: t.Errorf("Expected %v, but got %v", e, a) } <ins> // Test a simple id (using second ip). location, _, err = redirector.ResourceLocation(ctx, "foo-second-ip") if err != nil { t.Errorf("Unexpected error: %v", err) } if location == nil { t.Errorf("Unexpected nil: %v", location) } if e, a := "//[2001:db7::]:80", location.String(); e != a { t.Errorf("Expected %v, but got %v", e, a) } </ins> // Test a name + port. location, _, err = redirector.ResourceLocation(ctx, "foo:p") if err != nil {
Code change:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery

Related discussion:
text: t.Errorf("Expected %v, but got %v", e, a) } <ins> // Test a name + port (using second ip). location, _, err = redirector.ResourceLocation(ctx, "foo-second-ip:p") if err != nil { t.Errorf("Unexpected error: %v", err) } if location == nil { t.Errorf("Unexpected nil: %v", location) } if e, a := "//[2001:db7::]:93", location.String(); e != a { t.Errorf("Expected %v, but got %v", e, a) } </ins> // Test a name + port number (service port 93 -> target port 80) location, _, err = redirector.ResourceLocation(ctx, "foo:93") if err != nil {
Code change:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery

Related discussion:
text: t.Errorf("Expected %v, but got %v", e, a) } <ins> // Test a name + port number (service port 93 -> target port 80, using second ip) location, _, err = redirector.ResourceLocation(ctx, "foo-second-ip:93") if err != nil { t.Errorf("Unexpected error: %v", err) } if location == nil { t.Errorf("Unexpected nil: %v", location) } if e, a := "//[2001:db7::]:80", location.String(); e != a { t.Errorf("Expected %v, but got %v", e, a) } </ins> // Test a name + port number (service port 9393 -> target port "p" -> endpoint port 93) location, _, err = redirector.ResourceLocation(ctx, "foo:9393") if err != nil {
Code change:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery

Related discussion:
text: t.Errorf("Expected %v, but got %v", e, a) } <ins> // Test a name + port number (service port 9393 -> target port "p" -> endpoint port 93, using second ip) location, _, err = redirector.ResourceLocation(ctx, "foo-second-ip:9393") if err != nil { t.Errorf("Unexpected error: %v", err) } if location == nil { t.Errorf("Unexpected nil: %v", location) } if e, a := "//[2001:db7::]:93", location.String(); e != a { t.Errorf("Expected %v, but got %v", e, a) } </ins> // Test a scheme + name + port. location, _, err = redirector.ResourceLocation(ctx, "https:foo:p") if err != nil {
Code change:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery

Related discussion:
text: t.Errorf("Expected %v, but got %v", e, a) } <ins> // Test a scheme + name + port (using second ip). location, _, err = redirector.ResourceLocation(ctx, "https:foo-second-ip:p") if err != nil { t.Errorf("Unexpected error: %v", err) } if location == nil { t.Errorf("Unexpected nil: %v", location) } if e, a := "https://[2001:db7::]:93", location.String(); e != a { t.Errorf("Expected %v, but got %v", e, a) } </ins> // Test a non-existent name + port. location, _, err = redirector.ResourceLocation(ctx, "foo:q") if err == nil { t.Errorf("Unexpected nil error") } <ins> // Test a non-existent name + port (using second ip). location, _, err = redirector.ResourceLocation(ctx, "foo-second-ip:q") if err == nil { t.Errorf("Unexpected nil error") } </ins> // Test error path if _, _, err = redirector.ResourceLocation(ctx, "bar"); err == nil { t.Errorf("unexpected nil error")