jiebi/CodeConvo huggingface dataset:
Change:
t.Fatalf("bad cidr: %v", err) } cfg.ExtraConfig.ServiceIPRange = *cidr <ins> cfg.GenericConfig.PublicAddress = netutils.ParseIPSloppy("2001:db8::10") </ins> _, s, closeFn := framework.RunAnAPIServer(cfg) defer closeFn()

Discussion:
Clusters created with kubeadm using DualStack are not able to work, because CoreDNS pods never get ready Seeing one failed job logs It seems that the pod is "waiting for the kubernetes service"?? coredns version seems the same as in the working jobs CoreDNS pod should be ready Instal a Dual-stack cluster using master with kubeadm (or kind ) ! It started to fail on Oct12 <details</details<details</details<details</details<details</details<details</details<details</details
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
/cc I didn't notice it was failing for more than 1 month :facewithhead_bandage: I didn't have time to dig into it yet, but this PR landed just that day how is that the pods running has the version 1.8.4 but the PR seems to update kubeadm to 1.8.6?
Looking into this today. The error from CoreDNS should only happen when the kubernetes plugin fails to sync with the Kubernetes API, either because it can’t connect, or it can’t sync the lists of services/endpointslices. There were changes and fixes to the API connection code, so it could be a regression.
Actually no. The changes I was thinking of were already in 1.8.4.
How can we reproduce it : Instal a Dual-stack cluster using master with kubeadm (or kind ) I was unable to reproduce this issue in a kind dual stack cluster.

After upgrading coredns to 1.8.6 (from 1.8.0 installed by kind), and adding list/watch permission for endpointslice, the pods were ready. edit: It also works for coredns 1.8.4 - I'm unclear as to which version I should be checking.
let me check if is a regression in kind :thinking:
working with 1.8.6 and yesterdays kubernetes podIPs
This is weird, I hit a similar issue in openshift, endpoints doesn't match the IP family of the kubernetes.default service apiserver service is single stack, at least until this KEP fixes it What I don't understand is why the order of the IPs in kind is different let me try to fix both things /assign
my fault, sorry for the noise :sweat_smile:
Change:
} // tryUnmount calls plain "umount" and waits for unmountTimeout for it to finish. <del> func tryUnmount(mounter *Mounter, path string, unmountTimeout time.Duration) error { klog.V(4).Infof("Unmounting %s", path) </del> <ins> func tryUnmount(target string, withSafeNotMountedBehavior bool, unmountTimeout time.Duration) error { klog.V(4).Infof("Unmounting %s", target) </ins> ctx, cancel := context.WithTimeout(context.Background(), unmountTimeout) defer cancel() <del> cmd := exec.CommandContext(ctx, "umount", path) out, cmderr := cmd.CombinedOutput() </del> <ins> command := exec.CommandContext(ctx, "umount", target) output, err := command.CombinedOutput() </ins> // CombinedOutput() does not return DeadlineExceeded, make sure it's // propagated on timeout.

Discussion:
A status of Pod mounted NFS PV remain as terminating when a node shutdown and restart. A Pod is completely terminated. Deploy a Pod mounted NFS PV Shutdown the node where the Pod is running Wait for 5 min and the Pod status become Restart the node The Pod status is still and the Pod is never terminated completely <detailsPrepare a NFS Server.(I used ) Deploy a Pod mounted NFS PV like this. Shutdown the node where the Pod is running.(In this case ) And the status of node02 becomes . After 5 min later(by default), the Pod status becomes . (The time a Pod becomes status depends on .) Then, restart the node and the status of node02 becomes . But the Pod status is still and the Pod is never terminated completely. It seems that a faild to delete Pod because of trying to unmount a not mounted directory. Force delete Pod. Delete Pod's directory on the node. </detailsNo response <details</details<detailsnone(on premise) </details<details</details<details</details<details</details<details</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
/sig storage
/sig node
It dose not happen using , so it seems to depend on NFS volume plugin.
/assign
I try to build and run kubelet with comment out this logic. Then it seems to get well. related: This change checks the result of instead of the mount point check. However, check logic is not implemented in and (these functions are used in NFS volume plugin), despite it is done in .
/remove-sig node /sig storage
Reopening, fix had to be reverted due to unit tests requiring root permissions ()
I am terribly sorry... Please wait a moment. I'll try to fix it.
no worries, just get to review the rework, making sure the units tests don't require root permissions
Thank you! Fixed in .
Are there any plans to backport this to older Kubernetes versions? This seems like a critical fix.
Change:
// createServiceAccount creates a service account, and returns its name. func createServiceAccount(f *framework.Framework) string { <del> accountName := f.Namespace.Name + "-sa" </del> <ins> accountName := f.Namespace.Name + "-sa-" + string(uuid.NewUUID()) </ins> account := &v1.ServiceAccount{ ObjectMeta: metav1.ObjectMeta{ Name:      accountName,

Discussion:
Cluster api provides a framework to run the e2e tests which uses the conformance image: The gmsa tests use bash to install the webhook: The test will fail when run in the conformance image because of the bash: we should install the component another way run this e2e conformance image with /sig windows fyi <details</details<details</details<details</details<details</details<details</details<details</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
Conformance image:
Hi does the "work e2e" test case pass? Deploying GMSA webhook is the same for both "work e2e" and this test case.
no, they both fail due to bash not being present in the conformance image. The gmsa tests themselves pass if I run locally
/sig testing
Change:
t.Fatal("caches failed to sync") } <del> if dsc.queue.Len() != 0 { t.Fatal("Unexpected item in the queue") } </del> <ins> expectStableQueueLength(0) </ins> oldDS := newDaemonSet("test") oldDS, err = client.AppsV1().DaemonSets(oldDS.Namespace).Create(context.Background(), oldDS, metav1.CreateOptions{})

Discussion:
Which jobs are failing: TestExpectationsOnRecreate unit test, in along with expectations bugfix during 1.19 and cherry-picked to 1.18/1.17 Which test(s) are failing: Reason for failure: Anything else we need to know: These failures are masked in CI because bazel test runs with flake retries (), so the test can fail 2/3 times and the job can still pass (cc
adding to the milestone for triage, in case this is a real bug and not just a test issue /milestone v1.19
cc
/assign
looks like the panic is due to the test continuing in the !exists case (rather than exiting with a Fatal): however, that still means the test is failing in three distinct places:
it looks like the same failure existed in 1.18, so this probably isn't release blocking, but it does need to be resolved in order for us to stop ignoring unit test flakes in CI runs
it actually looks like this test was during the 1.19 dev cycle and cherry-picked back to 1.18/1.17, which is why release-1.18 is failing :-/
figured it out... the controller sync is updating the DS, which is triggering an update event and adding an extra enqueue which the test did not account for good news is that it appears to be a test-only issue
possible test deflake in
Change:
InPathCheck{executable: "touch", mandatory: false}, } <ins> if len(cfg.DiscoveryTokenAPIServers) > 0 { if ip := net.ParseIP(cfg.DiscoveryTokenAPIServers[0]); ip != nil { if ip.To4() == nil && ip.To16() != nil { checks = append(checks, FileContentCheck{Path: bridgenf6, Content: []byte{'1'}}, ) } } } </ins> return RunChecks(checks, os.Stderr) }

Discussion:
BUG REPORT /kind bug What happened: Kubeadm checks that bridge-nf-call-iptables (IPv4) is set, but does not check for bridge-nf-call-ip6tables (IPv6) What you expected to happen: If IPv6 is being used, then Kubeadm should check for bridge-nf-call-ip6tables How to reproduce it (as minimally and precisely as possible): Just running Kubeadm, however it's only a problem when running IPv6 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:
/area ipv6 /area kubeadm
/sig network
Change:
} storage := map[string]rest.Storage{} <del> if isEnabled("replicationcontrollers") { controllerStorage := expcontrolleretcd.NewStorage(c.StorageDestinations.get("", "replicationControllers")) storage["replicationcontrollers"] = controllerStorage.ReplicationController storage["replicationcontrollers/scale"] = controllerStorage.Scale } </del> if isEnabled("horizontalpodautoscalers") { autoscalerStorage, autoscalerStatusStorage := horizontalpodautoscaleretcd.NewREST(dbClient("horizonalpodautoscalers")) storage["horizontalpodautoscalers"] = autoscalerStorage storage["horizontalpodautoscalers/status"] = autoscalerStatusStorage <ins> controllerStorage := expcontrolleretcd.NewStorage(c.StorageDestinations.get("", "replicationControllers")) storage["replicationcontrollers"] = controllerStorage.ReplicationController storage["replicationcontrollers/scale"] = controllerStorage.Scale </ins> } if isEnabled("thirdpartyresources") { thirdPartyResourceStorage := thirdpartyresourceetcd.NewREST(dbClient("thirdpartyresources"))

Discussion:
e.g. scale up if CPU usage exceeds 70% of CPU request. Subtasks: [x] Add API changes [x] Add implementation [x] Add support in kubectl to print status with cpu request utilization [x] Add e2e tests
I've sent main PR for review (). During your day/my night please look into kubectl changes and e2e tests.
Change:
framework.Failf("waiting for csi driver node registration on: %v", err) } <del> // Cleanup CSI driver and namespaces. This function needs to be idempotent and can be // concurrently called from defer (or AfterEach) and AfterSuite action hooks. cleanupFunc := func() { ginkgo.By(fmt.Sprintf("deleting the test namespace: %s", testns)) // Delete the primary namespace but it's okay to fail here because this namespace will // also be deleted by framework.Aftereach hook tryFunc(func() { f.DeleteNamespace(testns) }) ginkgo.By("uninstalling csi gce-pd driver") tryFunc(cleanup) tryFunc(cancelLogging) ginkgo.By(fmt.Sprintf("deleting the driver namespace: %s", driverns)) tryFunc(func() { f.DeleteNamespace(driverns) }) // cleanup function has already ran and hence we don't need to run it again. // We do this as very last action because in-case defer(or AfterEach) races // with AfterSuite and test routine gets killed then this block still // runs in AfterSuite framework.RemoveCleanupAction(g.cleanupHandle) } g.cleanupHandle = framework.AddCleanupAction(cleanupFunc) </del> <ins> cleanupFunc := generateDriverCleanupFunc( f, "gce-pd", testns, driverns, cleanup, cancelLogging) </ins> return &storageframework.PerTestConfig{ Driver:          g,

Discussion:
Tracking bug for /sig storage /important-longterm /assign
/sig storage /triage accepted
/priority important-longterm
Change:
"//cmd/kubeadm/app/constants:go_default_library", "//cmd/kubeadm/app/features:go_default_library", "//cmd/kubeadm/app/util:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/validation:go_default_library", "//staging/src/k8s.io/client-go/util/cert:go_default_library", "//staging/src/k8s.io/client-go/util/keyutil:go_default_library",

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: Duplicate altnames in certs which generated by kubeadm ! What you expected to happen: No Duplicate altnames in certs which generated by kubeadm How to reproduce it (as minimally and precisely as possible): Anytime Anything else we need to know?: ! Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cluster-lifecycle
/area kubeadm
Can you describe your detailed usage scenarios and reproduction steps, and explain the kubernetes version so that we can quickly locate
Thank for your response! I have found why and will fix it soon.
i have commented on the PR. /priority awaiting-more-evidence
/remove-priority awaiting-more-evidence /priority backlog
Change:
"${NETWORK}-default-internal"  # Pre-1.5 clusters if [[ "${KUBE_DELETE_NETWORK}" == "true" ]]; then <ins> delete-cloud-nat-router </ins> # Delete all remaining firewall rules in the network. delete-all-firewall-rules || true delete-subnetworks || true

Discussion:
Public IPs are expensive resources. Given that we're running scalability tests on 5k-node clusters, we are unnecessarily consuming 5k IPs which is a lot. We should switch our tests so that nodes have only private IP addresses. We are going to do that by configuring NAT so that nodes can talk to outside world (e.g. to download image from dockerhub). But that also requires changing some correctness tests which assume public IPs.
To summarize recent work: setting up private gce clusters with nat, feature is gated via the env test and dashboard with correctness tests on gce private cluster - https://k8s- 27 tests fail on fixing the tests - should fix majority of them
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
/remove-lifecycle stale /lifecycle frozen
- is there anything missing to be done here?
No, we can close this one. It was done long time ago. Thanks for catching /close
Closing this issue. <detailsIn response to : No, we can close this one. It was done long time ago. Thanks for catching 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:
} func Test_extractKubeVersionTag(t *testing.T) { <ins> oldKlogOsExit := klog.OsExit defer func() { klog.OsExit = oldKlogOsExit }() klog.OsExit = customExit </ins> tests := []struct { name        string tagName     string

Discussion:
The commands under will benefit of a batter unit test coverage as seen in Originally posted by in
/sig api-machinery /assign
GitHub didn't allow me to assign the following users: damiansawicki. 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 : /sig api-machinery 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
/triage accepted
Hi I would like to work on this issue. Could you tell me how many test files are needed per PR under this issue?
Hi the issue is already assigned to me. Would you consider contributing to other issues to avoid duplication?
Hi do you mind if I work on this issue along with you? I would only like to write tests on limited number of files, if that's okay with you...
Hi thanks for your engagement! If you also want to work on this particular issue, we should coordinate. Are you working on something other than ?
Hey currently I'm thinking of shifting to Do let me know if you are already working on that particular directory. Also I could assist you in any of your work on this issue as I'm not preoccupied at the moment.
Change:
<ins> // +build !windows /* Copyright 2020 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package kuberuntime import ( "fmt" "k8s.io/api/core/v1" "k8s.io/kubernetes/pkg/securitycontext" ) // verifyRunAsNonRoot verifies RunAsNonRoot. func verifyRunAsNonRoot(pod *v1.Pod, container *v1.Container, uid *int64, username string) error { effectiveSc := securitycontext.DetermineEffectiveSecurityContext(pod, container) // If the option is not set, or if running as root is allowed, return nil. if effectiveSc == nil || effectiveSc.RunAsNonRoot == nil || !*effectiveSc.RunAsNonRoot { return nil } if effectiveSc.RunAsUser != nil { if *effectiveSc.RunAsUser == 0 { return fmt.Errorf("container's runAsUser breaks non-root policy") } return nil } switch { case uid != nil && *uid == 0: return fmt.Errorf("container has runAsNonRoot and image will run as root") case uid == nil && len(username) > 0: return fmt.Errorf("container has runAsNonRoot and image has non-numeric user (%s), cannot verify user is non-root", username) default: return nil } } </ins>

Discussion:
Hello, What happened: When we apply PodSecurityPolicy with rule: WIndows containers are still blocked instead we put: the pod is still blocked with logs: What you expected to happen: the Container should start How to reproduce it (as minimally and precisely as possible): Create Psp disableling Root Users: Create a pod Windows with runAsUserName: Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.3 Cloud provider or hardware configuration: OS (e.g: ): CentOS Linux 7 (Core) / windows server 2019 version 1809 Kernel (e.g. ): 3.10.0-514.10.2.el7.x86_64 Others: /sig windows
/sig windows
/assign I will test it and then post the test results
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
Change:
Description:     k8sNodeRouteTag, }).Do() if err != nil { <del> return err </del> <ins> if isHTTPErrorCode(err, http.StatusConflict) { glog.Info("Route %v already exists.") return nil } else { return err } </ins> } return gce.waitForGlobalOp(insertOp) }

Discussion:
In large clusters, I'm seeing logs like this coming from route controller: Logs from route controller for that node:
OK - so the "rate limit exceeded" errors were caused by colliding tests in the same project. So the problems are that: timeout seems to be too low we are not handling errors exactly as we should
The first one is fixed by
Second problem was fixed by . Can we close this?
Yes.
Change:
}, { libipvs.Service{ <ins> Protocol:      0, Port:          0, FWMark:        0, SchedName:     "mh", Flags:         uint32(FlagPersistent + FlagHashed + FlagSourceHash), Timeout:       0, Netmask:       0xffffffff, AddressFamily: unix.AF_INET, Address:       netutils.ParseIPSloppy("1.2.3.4"), PEName:        "", }, VirtualServer{ Address:   netutils.ParseIPSloppy("1.2.3.4"), Protocol:  "", Port:      0, Scheduler: "mh", Flags:     ServiceFlags(FlagPersistent + FlagSourceHash), Timeout:   0, }, false, "", }, { libipvs.Service{ </ins> Protocol:      unix.IPPROTO_SCTP, Port:          80, FWMark:        0,

Discussion:
The current support of the load distribution method and in kube-proxy ipvs mode only performs hashing of source IP address to select endpoints. As a result, all connections from a single client (i.e. from a particular source IP) are always forwarded to only one endpoint matching with the hash value of this source IP. If the client opens a vast majority of connections to the k8s cluster, it will result in traffic imbalance as only one endpoint located on one node handles the connections while the remaining endpoints/nodes are idle. Here is an example of the problem when using method for kube-proxy Deploy a service with 4 endpoints located on 4 nodes.Open 200 connections from a client to node IP of any node (e.g. telnet 192.168.1.1 ). All connections receive replies from only one single endpoint.The distribution printout also shows that all connections are forwarded to the endpoint (e.g. 1.0.4.2:5001 in this example)Similar issue is seen with method Connections from a client should be evenly distributed to all endpoints like to avoid unbalanced load distribution between cluster nodes and endpoints. This can be easily done by enabling the source port hash flag that IPVS supports for the methods which performs hashing on both source IP and source port when selecting the target endpoint.
/sig network /area kube-proxy /area ipvs
This issue was raised based on the discussion of the issue
triage/accepted /assign
/triage/accepted
/triage accepted (damn it!)