jiebi/CodeConvo huggingface dataset:
Code change:
return err } if !mountPoint { <del> return fmt.Errorf("azureDisk - Not a mounting point for disk %s on %s", diskName, dir) </del> <ins> glog.V(4).Infof("azureDisk - already mounted to target %s", dir) return nil </ins> } if err := os.MkdirAll(dir, 0750); err != nil {

Related discussion:
text: <!-- 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: There will be error when kubelet restarts on a agent if pod in that agent has an azure disk mounted, the error would be like following: azureDisk - No t a mounting point for disk andykubewin175-dynamic-pvc--92c7-11e7-b86b- on varlibkubeletpods-92c7-11e7-b86b-volumespvc--92c7-11 e7-b86b- What you expected to happen: pod could still works well even if kubelet restarts on the agent How to reproduce it (as minimally and precisely as possible): consider following scenario: A pod mounting an azure disk in a k8s agent The kubelet is restarted in that k8s agent The pod could not start up, it always reports error as following: 4d 1m 3065 kubelet, 14777acs9000 Warning FailedMount MountVolume.SetUp failed for volume "pvc--92c7-11e7-b86b-" : azureDisk - No t a mounting point for disk andykubewin175-dynamic-pvc--92c7-11e7-b86b- on varlibkubeletpods-92c7-11e7-b86b-volumespvc--92c7-11 e7-b86b- 4d 1m 3157 kubelet, 14777acs9000 Warning FailedMount Error syncing pod Anything else we need to know?: Environment: Kubernetes version (use ): 1.7, 1.8 Cloud provider or hardware configuration**: azure OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
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 .
Code change:
return err } if !mountPoint { <del> return fmt.Errorf("azureDisk - Not a mounting point for disk %s on %s", diskName, dir) </del> <ins> glog.V(4).Infof("azureDisk - already mounted to target %s", dir) return nil </ins> } if err := os.MkdirAll(dir, 0750); err != nil {

Related discussion:
text: The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig azure
/assign andyzhangx
Code change:
if len(q.nominatedPods.nominatedPods["node1"]) != 2 { t.Errorf("Expected medPriorityPod and unschedulablePod to be still present in nomindatePods: %v", q.nominatedPods.nominatedPods["node1"]) } <del> if q.unschedulableQ.get(&highPriNominatedPod) != &highPriNominatedPod { </del> <ins> if getUnschedulablePod(q, &highPriNominatedPod) != &highPriNominatedPod { </ins> t.Errorf("Pod %v was not found in the unschedulableQ.", highPriNominatedPod.Name) } }

Related discussion:
text: Which jobs are failing: pull-kubernetes-bazel-test Which test(s) are failing: bazel test //pkg/scheduler/internal/queue:godefaulttest Since when has it been failing: Testgrid link: Reason for failure: WARNING: DATA RACE Read at 0x00c000230db0 by goroutine 47: runtime.mapiterinit() +0x0 (PriorityQueue).flushUnschedulableQLeftover() +0x17a (PriorityQueue).flushUnschedulableQLeftover-fm() +0x41 () +0x61 () +0xce () +0x5a Previous write at 0x00c000230db0 by goroutine 45: runtime.mapassignfaststr() +0x0 (UnschedulablePodsMap).addOrUpdate() +0x30e () +0x601 testing.tRunner() +0x162 Goroutine 47 (running) created at: (PriorityQueue).run() +0x172 () +0xe0b () +0x50 () +0x5a5 testing.tRunner() +0x162 Goroutine 45 (running) created at: testing.(T).Run() +0x659 testing.runTests.func1() +0xa8 testing.tRunner() +0x162 testing.runTests() +0x4ee testing.(M).Run() +0x2ee () bazel-out/k8- +0x2fb Anything else we need to know: I'm very sorry about that. UnschedulablePodsMap is not thread-safe. In , lock will be acquired before operating UnschedulablePodsMap. But in , lock isn‘t be acquired. In the previous case, only a single thread runs so it's ok. But after add goroutine , there will be data race. So I need to acquire lock before operating UnschedulablePodsMap.
/sig testing /sig scheduling
Code change:
return "", err } <del> return image.TagFromImage(pod.Spec.Containers[0].Image), nil </del> <ins> return convertImageTagMetadataToSemver(image.TagFromImage(pod.Spec.Containers[0].Image)), nil } // convertImageTagMetadataToSemver converts imagetag in the format of semver_metadata to semver+metadata func convertImageTagMetadataToSemver(tag string) string { // Container registries do not support `+` characters in tag names. This prevents imagetags from // correctly representing semantic versions which use the plus symbol to delimit build metadata. // Kubernetes uses the convention of using an underscore in image registries to preserve // build metadata information in imagetags. return strings.Replace(tag, "_", "+", 1) </ins> }

Related discussion:
text: <!-- 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 --When attempting to upgrade kubernetes using kubeadm upgrade apply, kubeadm fails to parse an etcd imagetag containing build metadata in the form of as a valid semver. An example upgrade produces an error similar to: Note this will occur even if the etcd version is unchanged. The +` character. This pattern is used to support custom kubernetes images, for instance kube-apiserver:v1.20.4+patch.0 will be converted to imagetag v1.20.4_patch.0 when running make quick-release-images. Add the following to kubeadm- Install kubernetes. Then upgrade kubernetes with kubeadm upgrade apply. I have tested a fix for this issue and will PR shortly. Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: kubeadm Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cluster-lifecycle
/area kubeadm
/triage accepted
Code change:
// In case of failure or too long waiting time, an error is returned. func waitForRCPodToDisappear(c *client.Client, ns, rcName, podName string) error { label := labels.SelectorFromSet(labels.Set(map[string]string{"name": rcName})) <del> return waitForPodToDisappear(c, ns, podName, label, 20*time.Second, 5*time.Minute) </del> <ins> // NodeController evicts pod after 5 minutes, so we need timeout greater than that. // Additionally, there can be non-zero grace period, so we are setting 10 minutes // to be on the safe size. return waitForPodToDisappear(c, ns, podName, label, 20*time.Second, 10*time.Minute) </ins> } // waitForService waits until the service appears (exist == true), or disappears (exist == false)

Related discussion:
text: Nodes Network when a minion node becomes unreachable [replication controller] recreates pods scheduled on the unreachable minion node AND allows scheduling of pods on a minion after it rejoins the cluster(Failed 17 times in the last 30 runs. Stability: 43 %)Failed with 0 retries
for triage
I'll look into this.
I talked to about this and he had a pretty good guess in about two seconds about what the problem is. ReplicationController sync method does this: but DaemonSet controller doesn't. (I guess when DaemonSet was copy-pasted from ReplicationController, this was accidentally removed.) Pod reflector and syncer are running in separate goroutines, and if pod reflector doesn't run then syncer will think there are no pods on the node.
To be clear: this is about the test Controller Manager should not create/delete replicas across restart which is the one that is actually failing.
I'm confused you're saying that this is about , but you're updating . I thought they are about two different tests...
Yes sorry, I put my comment in the wrong issue. Reassigning this one to you, and I'll copy my comment into the other one.
First failure: We check if all namespace are deleted. If other tests failed to delete their namespace this test will fail. I'm going to delete this logic as we already check if we have successfully deleted our namespace. See also for some more details.
Second failure: We disable network by running the following command: I checked and it seems that it results in ing master to hang. I suspect that Kubelet hangs on updating node status and depending when it breaks the connection (by timeout) it will fit in test timeouts or not.
What is the default timeout for connections using client libraries to apiserver? I'm checking the code, but can't find it.
I'm not sure if we set one, but we should. I guess I would expect to see that in the config, w/ default set by this function: , Filip Grzadkowski wrote:
So: let's add a timeout, and revert .
I think that adding a timeout and reverting are orthogonal. I we want to simulate network problems with node-master communication then using REJECT is better anyway. At the same time adding timeout makes sense for many other reasons.
Code change:
// In case of failure or too long waiting time, an error is returned. func waitForRCPodToDisappear(c *client.Client, ns, rcName, podName string) error { label := labels.SelectorFromSet(labels.Set(map[string]string{"name": rcName})) <del> return waitForPodToDisappear(c, ns, podName, label, 20*time.Second, 5*time.Minute) </del> <ins> // NodeController evicts pod after 5 minutes, so we need timeout greater than that. // Additionally, there can be non-zero grace period, so we are setting 10 minutes // to be on the safe size. return waitForPodToDisappear(c, ns, podName, label, 20*time.Second, 10*time.Minute) </ins> } // waitForService waits until the service appears (exist == true), or disappears (exist == false)

Related discussion:
text: OK then, let's add a timeout and test both DROP and REJECT-- no sort of network problem should hang a component.
I think it didn't hang. It just that the kubelet was retrying too slow and sometimes it fit test timeout, sometime it didn't.
Could we reduce the timeout to make it always fit the test timeout? , Filip Grzadkowski
I guess we can. I'll try tomorrow.
It seems we have a new type of failure: It seems that kubelet on a machine where network is blocked doesn't notice new pod. After reading logs I assume that kubelet doesn't notice that the watch is broken and doesn't try to relist everything. It notices new pod only after watch timeout.
Ugh, I hope we don't have to start sending watch heartbeats.
It seems that all recent failures are with the following error: which means the reason is here: - can you please take a look or delegate?
I did some more debugging of it. I was looking into this failure: There is something strange happening here: run performTemporaryNetworkFailure: succesfully block the load from kubelet: the succesfully wait for node to become not ready: some time nodecontroller successfully removes the pod: replication controller creates a new pod: here is something I don't undertand - because of some reason, the test doesn't observe that the pod actually disappeared. - any thoughts on it?
BTW - this is exactly the same situation in:
OK - I think this is related to default 30s deletion grace period.
Yes - it seems that this is exactly the case. I will send out PR fixing this out for review.
I'm reopening it for tracking. If there won't be any failures within next few days - I will move the test back from flaky and close this issue.
Thanks for fixing, .
It seems that the main issue is fixed. However, there was one failure in the last 30 runs: in which one pod simply didn't started (and it was "preparation" for the test, not the test itself).
During next 2 days there was exactly one more failure of this test: it is exactly the same as the previous one. However, those are duplicates of So I'm going to move this test out of flaky suite.
Code change:
if utilfeature.DefaultFeatureGate.Enabled(features.CSIDriverRegistry) { csiClient := host.GetKubeClient() if csiClient == nil { <del> return errors.New("unable to get Kubernetes client") </del> <ins> klog.Warning(log("kubeclient not set, assuming standalone kubelet")) } else { // Start informer for CSIDrivers. factory := csiapiinformer.NewSharedInformerFactory(csiClient, csiResyncPeriod) p.csiDriverInformer = factory.Storage().V1beta1().CSIDrivers() p.csiDriverLister = p.csiDriverInformer.Lister() go factory.Start(wait.NeverStop) </ins> } <del> // Start informer for CSIDrivers. factory := csiapiinformer.NewSharedInformerFactory(csiClient, csiResyncPeriod) p.csiDriverInformer = factory.Storage().V1beta1().CSIDrivers() p.csiDriverLister = p.csiDriverInformer.Lister() go factory.Start(wait.NeverStop) </del> } // Initializing the label management channels

Related discussion:
text: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: Since when has it been failing: It has been consistently failing since 3/6, flaking a lot before that. Failure coincides with . Testgrid link: Reason for failure: cc /kind flake /kind failing-test /priority important-soon /milestone v1.14 /sig cluster-lifecycle
sig gcp may be of help here /sig gcp
/assign for routing from SCL side. These are google owned tests.
Looking into this now. Any other googlers also doing so feel free to ping me :-)
Looks like this bug is known with a fix in flight: cc
/assign
Thanks ! Will keep an eye on this for 5 consistent passes, will reopen if there's a problem.
/reopen Most gke jobs are able to create clusters now, however the serial jobs are still seeing failures
Reopened this issue. <detailsIn response to : /reopen Most gke jobs are able to create clusters now, however the serial jobs are still seeing failures 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
Nevermind, it's because the serial job with the fix is still running. I've verified that the cluster creation succeeds in the latest job. /close
Closing this issue. <detailsIn response to : Nevermind, it's because the serial job with the fix is still running. I've verified that the cluster creation succeeds in the latest job. /close 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
/area platform/gke <img width="1106" alt="Screen Shot 2019-03-16 at 12 00 52 PM" src="https://user-"Think we're done here
Code change:
// EnsureDesiredReplicasInRange ensure the replicas is in a desired range func (rc *ResourceConsumer) EnsureDesiredReplicasInRange(ctx context.Context, minDesiredReplicas, maxDesiredReplicas int, duration time.Duration, hpaName string) { interval := 10 * time.Second <del> err := wait.PollUntilContextTimeout(ctx, interval, duration, true, func(ctx context.Context) (bool, error) { replicas := rc.GetReplicas(ctx) framework.Logf("expecting there to be in [%d, %d] replicas (are: %d)", minDesiredReplicas, maxDesiredReplicas, replicas) as, err := rc.GetHpa(ctx, hpaName) if err != nil { framework.Logf("Error getting HPA: %s", err) } else { framework.Logf("HPA status: %+v", as.Status) } if replicas < minDesiredReplicas { return false, fmt.Errorf("number of replicas below target") } else if replicas > maxDesiredReplicas { return false, fmt.Errorf("number of replicas above target") } else { return false, nil // Expected number of replicas found. Continue polling until timeout. } }) // The call above always returns an error, but if it is timeout, it's OK (condition satisfied all the time). if wait.Interrupted(err) { framework.Logf("Number of replicas was stable over %v", duration) return </del> <ins> desiredReplicasErr := framework.Gomega().Consistently(ctx, func(ctx context.Context) int { return rc.GetReplicas(ctx) }).WithTimeout(duration).WithPolling(interval).Should(gomega.And(gomega.BeNumerically(">=", minDesiredReplicas), gomega.BeNumerically("<=", maxDesiredReplicas))) // dump HPA for debugging as, err := rc.GetHpa(ctx, hpaName) if err != nil { framework.Logf("Error getting HPA: %s", err) } else { framework.Logf("HPA status: %+v", as.Status) </ins> } <del> framework.ExpectNoErrorWithOffset(1, err) </del> <ins> framework.ExpectNoError(desiredReplicasErr) </ins> } // Pause stops background goroutines responsible for consuming resources.

Related discussion:
text: [It] [sig-autoscaling] [Feature:HPA] [Serial] [Slow] Horizontal pod autoscaling (non-default behavior) with both scale up and down controls configured should keep recommendation within the range over two stabilization windows [sig-autoscaling, Feature:HPA, Serial, Slow] 11/3/2023 <*fmt.wrapError | 0xc000812080: client rate limiter Wait returned an error: context deadline exceeded { msg: "client rate limiter Wait returned an error: context deadline exceeded", err: <context.deadlineExceededError{}, } looks similiar to /sig autoscaling /sig windows
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
Code change:
ginkgo.It("should always delete fast (ALL of 100 namespaces in 150 seconds) [Feature:ComprehensiveNamespaceDraining]", func() { extinguish(f, 100, 0, 150) }) <ins> ginkgo.It("should patch a Namespace", func() { ginkgo.By("creating a Namespace") namespaceName := "nspatchtest-" + string(uuid.NewUUID()) ns, err := f.CreateNamespace(namespaceName, nil) framework.ExpectNoError(err, "failed creating Namespace") namespaceName = ns.ObjectMeta.Name ginkgo.By("patching the Namespace") nspatch, err := json.Marshal(map[string]interface{}{ "metadata": map[string]interface{}{ "labels": map[string]string{"testLabel": "testValue"}, }, }) framework.ExpectNoError(err, "failed to marshal JSON patch data") _, err = f.ClientSet.CoreV1().Namespaces().Patch(namespaceName, types.StrategicMergePatchType, []byte(nspatch)) framework.ExpectNoError(err, "failed to patch Namespace") ginkgo.By("get the Namespace and ensuring it has the label") namespace, err := f.ClientSet.CoreV1().Namespaces().Get(namespaceName, metav1.GetOptions{}) framework.ExpectNoError(err, "failed to get Namespace") framework.ExpectEqual(namespace.ObjectMeta.Labels["testLabel"], "testValue", "namespace not patched") }) </ins> })

Related discussion:
text: This issue proposes the writing of a new test for the API endpoint with the intention of promoting it to Conformance. This issue contains a very masic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to this query, there is only one API endpoint which is for Namespace that isn't being covered. We selected patchCoreV1Namespace to write a test for. Dependencies: The mock test: If a test with these calls is build and merged, conformance will go up by 1 endpoint.
/sig testing /sig architecture /area conformance
Code change:
var map_EnvVarSource = map[string]string{ "":                 "EnvVarSource represents a source for the value of an EnvVar.", <del> "fieldRef":         "Selects a field of the pod: supports metadata.name, metadata.namespace, metadata.labels, metadata.annotations, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs.", </del> <ins> "fieldRef":         "Selects a field of the pod: supports metadata.name, metadata.namespace, `metadata.labels['<KEY>']`, `metadata.annotations['<KEY>']`, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs.", </ins> "resourceFieldRef": "Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported.", "configMapKeyRef":  "Selects a key of a ConfigMap.", "secretKeyRef":     "Selects a key of a secret in the pod's namespace",

Related discussion:
text: <!-- 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 tried to create a pod with env variables referencing to annotations: What you expected to happen: Should Proceed. As in It stated is a valid option How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.2 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 docs
The API docs need to be updated to indicate the correct supported values. See for correct values
You are a lifesaver. Thank you!
/assign I can try to update the api documentation
Code change:
safeIpset := newSafeIpset(ipset) <ins> nodePortAddresses4, nodePortAddresses6 := utilproxy.FilterIncorrectCIDRVersion(nodePortAddresses, false) </ins> // Create an ipv4 instance of the single-stack proxier ipv4Proxier, err := NewProxier(ipt[0], ipvs, safeIpset, sysctl, exec, syncPeriod, minSyncPeriod, filterCIDRs(false, excludeCIDRs), strictARP, tcpTimeout, tcpFinTimeout, udpTimeout, masqueradeAll, masqueradeBit, localDetectors[0], hostname, nodeIP[0], <del> recorder, healthzServer, scheduler, nodePortAddresses, kernelHandler) </del> <ins> recorder, healthzServer, scheduler, nodePortAddresses4, kernelHandler) </ins> if err != nil { return nil, fmt.Errorf("unable to create ipv4 proxier: %v", err) }

Related discussion:
text: What happened: In a dual-stack cluster when specifying both ipv6 and ipv4 addresses in the entries are inserted in ipvs for the ipv6 nodeports but with an invalid ipv4 address; The example shows the ipv4 loopback address but any ipv4 address in will cause a faulty entry. What you expected to happen: No ipv4 entry shall be inserted for the ipv6 nodeport. How to reproduce it (as minimally and precisely as possible): Configure with both ipv4 and ipv6 addresses Bring up a dual-stack cluster with proxy-mode Create a service with ipFamily:IPv6 Do Anything else we need to know?: Proxy-mode=iptables seems to work. With no ipv4 entries are inserted for ipv6 nodeports. In it is recommended to use but doing so makes kube-proxy enter rules for address (in addition to "127.0.0.1"). While these entries cause no harm they can't be used and should not be there. These entries are created for both proxy-mode "iptables" and "ipvs". This should not be handled in this issue but in another (new) issue if needed. Example; Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Kvm's on Ubuntu OS (e.g: ): xcluster Kernel (e.g. ):Install tools: "from scratch" Network plugin and version (if this is a network-related bug): calico/cni:v3.12.0 Others: /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/area ipvs /area ipv6
/remove-triage unresolved /assign I take this myself if no one objects.
The ipv4 address is obviously a ipv4-converted ipv6 from .
According to the code here (), we may need to filter the before passing it to .
Looks that that's it. Please go ahead and make a PR, or I can do it if you prefer. I will help test the PR of course. Here are some review comments right away; Use v1.IPFamily as param to the filter function rather than The filter function seem usable and generic and may be placed in some "util" package, but leave it as-is and let the maintainers decide that.
Hi feel free to send a PR please, as you have took this already :) I'd like to help review it!
The "addresses" are really CIDRs which make the fix even simpler.