jiebi/CodeConvo huggingface dataset:
Change:
} else { // We only share the refCounts for remote endpoints ep.refCount = proxier.endPointsRefCount.getRefCount(newHnsEndpoint.hnsID) <ins> *ep.refCount++ </ins> } ep.hnsID = newHnsEndpoint.hnsID <del> *ep.refCount++ </del> Log(ep, "Endpoint resource found", 3) }

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 --kube-proxy panics when a LoadBalancer service is created after a deployment it is associated with is created and the pods are fully running. kube-proxy does not panic. 1) Create 2 Windows nodes 2) Create a deployment, ensuring that the pods are scheduled on different nodes: 3) Wait for the pods to go into the state. kube-proxy will not crash if the pods are not fully deployed 4) Create a LoadBalancer service for the deployment 5) At this point kube-proxy should have crashed. If not, delete and recreate the LoadBalancer, this should trigger the panic. The kube-proxy exe was run as: Stdout/err shows: Full kube-proxy logs: Kubernetes version (use ): 1.20 Cloud provider or hardware configuration: AWS OS (e.g: ): Windows server 2019 Kernel (e.g. ): 10.0..1817 Install tools: OpenShift 4.7.3 Network plugin and version (if this is a network-related bug): Hybrid OVN Others:
/sig windows
are you aware of anything happening here?
I am taking a look at this.
/triage accepted
Change:
name: coredns namespace: kube-system labels: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile kubernetes.io/name: "CoreDNS" spec: <del> replicas: 2 </del> <ins> # replicas: not specified here: # 1. In order to make Addon Manager do not reconcile this replicas parameter. # 2. Default is 1. # 3. Will be tuned in real time if DNS horizontal auto-scaling is turned on. </ins> strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 selector: matchLabels: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> template: metadata: labels: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> spec: serviceAccountName: coredns tolerations:

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: e2e test "gci-gce" is running in 2 versions: with kube-dns as DNS Service : https://k8s- with CoreDNS as DNS Service : https://k8s- In CoreDNS use case the test is failing What you expected to happen: This e2e tests should not depend on what DNS service is running as default in K8s. CoreDNS is currently BETA, will move to GA soon (after v1.10 though) See : How to reproduce it (as minimally and precisely as possible): look at logs of dashboard : https://k8s- go run -v --test --test_args='--[sig-autoscaling]sDNSshorizontalsautoscalings[DisabledForLargeClusters]skube-dns-autoscalersshouldsscaleskube-dnsspodssinsbothsnonfaultysandsfaultysscenarios$' Anything else we need to know?: Environment: Kubernetes version (use ): branch master Cloud provider or hardware configuration: GCE Install tools: deployment intra-test Others: see https://k8s-
/sig autoscaling
/unsig cli
Looks like the test is searching specifically for a deployment labeled "kube-dns". There are several references to "kube-dns" scattered around it, actually.
Right now the tool "dns-horizontal-autoscaller" seems dedicated for kube-dns. This tools is deployed as "add-on" when enabled by this ENV variable : I guess we should have the definition of another dns-horizontal-autoscaller, dedicated to coredns (unless we generate the yaml file). and the choice of deployment is based on the ENV variable . see
Currently, the translation of the deployment of "dns-horizontal-autoscaller" for CoreDNS is in progress by It is expected that the corresponding e2e test will work as is (as the artifacts are selected by labels, which are the same for CroeDNS and kube-dns).
Change:
panic(err) } } <ins> func convert_v1_StatusDetails_To_api_StatusDetails(in *StatusDetails, out *api.StatusDetails, s conversion.Scope) error { if defaulting, found := s.DefaultingInterface(reflect.TypeOf(*in)); found { defaulting.(func(*StatusDetails))(in) } out.ID = in.Name out.Kind = in.Kind if in.Causes != nil { out.Causes = make([]api.StatusCause, len(in.Causes)) for i := range in.Causes { if err := convert_v1_StatusCause_To_api_StatusCause(&in.Causes[i], &out.Causes[i], s); err != nil { return err } } } else { out.Causes = nil } out.RetryAfterSeconds = in.RetryAfterSeconds return nil } func convert_api_StatusDetails_To_v1_StatusDetails(in *api.StatusDetails, out *StatusDetails, s conversion.Scope) error { if defaulting, found := s.DefaultingInterface(reflect.TypeOf(*in)); found { defaulting.(func(*api.StatusDetails))(in) } out.Name = in.ID out.Kind = in.Kind if in.Causes != nil { out.Causes = make([]StatusCause, len(in.Causes)) for i := range in.Causes { if err := convert_api_StatusCause_To_v1_StatusCause(&in.Causes[i], &out.Causes[i], s); err != nil { return err } } } else { out.Causes = nil } out.RetryAfterSeconds = in.RetryAfterSeconds return nil } func convert_v1_StatusCause_To_api_StatusCause(in *StatusCause, out *api.StatusCause, s conversion.Scope) error { if defaulting, found := s.DefaultingInterface(reflect.TypeOf(*in)); found { defaulting.(func(*StatusCause))(in) } out.Type = api.CauseType(in.Type) out.Message = in.Message out.Field = in.Field return nil } func convert_api_StatusCause_To_v1_StatusCause(in *api.StatusCause, out *StatusCause, s conversion.Scope) error { if defaulting, found := s.DefaultingInterface(reflect.TypeOf(*in)); found { defaulting.(func(*api.StatusCause))(in) } out.Type = CauseType(in.Type) out.Message = in.Message out.Field = in.Field return nil } </ins>

Discussion:
When accessing a non existing entity (example - namespace), the message specifies the requested field as 'id', but it should be 'name'. Example (see the details section) { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "namespaces "staging" not found", "reason": "NotFound", "details": { "id": "staging", "kind": "namespaces" }, "code": 404 }
Yes. We should rename "id" to "name" in StatusDetails: Not sure if we can change v1beta3 API now. cc
You can add a new field and fill in both, and MAYBE remove ID in v1 , Nikhil Jindal wrote:
I suggest we fix it at most in v1 only. This is an annoying wart, but we could just fix the description string for now.
If trivial, we should fix v1.
Change:
"Rev": "6633656539c1639d9d78127b7d47c622b5d7b6dc" }, { <ins> "ImportPath": "github.com/influxdb/influxdb/client", "Comment": "v0.8.8", "Rev": "afde71eb1740fd763ab9450e1f700ba0e53c36d0" }, { </ins> "ImportPath": "github.com/kr/pty", "Comment": "release.r56-25-g05017fc", "Rev": "05017fcccf23c823bfdea560dcc958a136e54fb7"

Discussion:
Due to changes in field selectors (see ) heapster was almost certainly busted, but continues to pass. This seems incorrect.
Change:
// assert that unwanted pods were killed fakeRuntime.AssertKilledPods([]string{"12345678"}) <ins> // simulate Runtime.KillPod fakeRuntime.PodList = nil </ins> kubelet.HandlePodCleanups() kubelet.HandlePodCleanups() kubelet.HandlePodCleanups()

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: Right after calling , returns false even the pod is not killed yet. What you expected to happen: In kubelet, after is complete, the pod should be pending termination or be killed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Related to 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:
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 node /assign
Change:
klog.V(2).Infof("GetDiskLun returned: %v. Initiating attaching volume %q to node %q.", err, volumeSource.DataDiskURI, nodeName) isManagedDisk := (*volumeSource.Kind == v1.AzureManagedDisk) <del> err = diskController.AttachDisk(isManagedDisk, volumeSource.DiskName, volumeSource.DataDiskURI, nodeName, compute.CachingTypes(*volumeSource.CachingMode)) </del> <ins> lun, err = diskController.AttachDisk(isManagedDisk, volumeSource.DiskName, volumeSource.DataDiskURI, nodeName, compute.CachingTypes(*volumeSource.CachingMode)) </ins> if err == nil { klog.V(2).Infof("Attach operation successful: volume %q attached to node %q.", volumeSource.DataDiskURI, nodeName) } else {

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: What you expected to happen: How to reproduce it (as minimally and precisely as possible): 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 azure /assign
Change:
docker build -t in-cluster . If you are not using Minikube, you should build this image and push it to a registry <del> that your Kubernetes cluster can pull from. If you have RBAC enabled, use the following </del> <ins> that your Kubernetes cluster can pull from. If you have RBAC enabled on your cluster, use the following </ins> snippet to create role binding which will grant the default service account view permissions.

Discussion:
What would you like to be : Clarify the example in . Specifically, this paragraph: Why is this needed: When read in the context of the rest of the document, because of the way it is written, it suggests that the following step is unnecessary if you are using Minikube. In fact, it is necessary with the latest version of Minikube, and when this is not done, the command hangs with no output.
/sig docs
Change:
It("should be submitted and removed", func() { podClient := c.Pods(api.NamespaceDefault) <del> By("loading the pod json") pod := loadPodOrDie(assetPath("api", "examples", "pod.json")) </del> <ins> By("creating the pod") name := "pod-update-" + string(util.NewUUID()) </ins> value := strconv.Itoa(time.Now().Nanosecond()) <del> pod.Name = pod.Name + "-" + randomSuffix() pod.Labels["time"] = value pod.Spec.Containers[0].Ports[0].HostPort = 0 </del> <ins> pod := &api.Pod{ ObjectMeta: api.ObjectMeta{ Name: name, Labels: map[string]string{ "name": "foo", "time": value, }, }, Spec: api.PodSpec{ Containers: []api.Container{ { Name:  "nginx", Image: "dockerfile/nginx", Ports: []api.Port{{ContainerPort: 80}}, LivenessProbe: &api.Probe{ Handler: api.Handler{ HTTPGet: &api.HTTPGetAction{ Path: "/index.html", Port: util.NewIntOrStringFromInt(8080), }, }, InitialDelaySeconds: 30, }, }, }, }, } </ins> By("submitting the pod to kubernetes") _, err := podClient.Create(pod)

Discussion:
rebase raced with change and missed a line in commit , leaving that test referencing the old file.
Change:
DryRunStrategy cmdutil.DryRunStrategy // OnPodDeletedOrEvicted is called when a pod is evicted/deleted; for printing progress output <ins> // Deprecated: use OnPodDeletionOrEvictionFinished instead </ins> OnPodDeletedOrEvicted func(pod *corev1.Pod, usingEviction bool) <ins> // OnPodDeletionOrEvictionFinished is called when a pod is eviction/deletetion is failed; for printing progress output OnPodDeletionOrEvictionFinished func(pod *corev1.Pod, usingEviction bool, err error) // OnPodDeletionOrEvictionStarted is called when a pod eviction/deletion is started; for printing progress output OnPodDeletionOrEvictionStarted func(pod *corev1.Pod, usingEviction bool) </ins> } type waitForDeleteParams struct {

Discussion:
kubedrain has "onPodDeletedOrEvicted" callback that can be used in custom controllers. It would be very helpful if we add more callbacks that can give more granular control over monitoring, like "onPodDeletionOrEvicitionStarted" and "onPodDeletionOrEvictionFailed". It would help monitor the draining of nodes on a more granular level. Sometimes while draining, if the pod is stuck during the eviction or deletion of node, there is not much information that custom controllers can get from kubedrain, with the above-mentioned callbacks custom controllers will know which pod is evicting or if it failed during the eviction process.
/sig node
What is the custom controllers in your scenario? Can you elaborate on what you want to achieve with more details. Is this is kubectl improvement, the best sig to involve is sig cli. /sig cli
/remove-sig node please re-apply the sig node if this will end up being a request to sig node
In our case we have in CAPI (). Sometimes while draining, if the pod or volume is stuck during the eviction, there is not much information that we get from kubedrain.Helper. It would be much easier for the controller to report these kinds of issues with more granular callbacks like "onPodDeletionOrEvicitionStarted" and "onPodDeletionOrEvictionFailed" on kubedrain.Helper.
/assign Assigning this to myself, I have discussed this issue in sig-cli community meeting and they have given green light for this improvement.
/triage accepted /priority backlog
Change:
info.Refresh(patchedObject, true) <del> visitedUids.Insert(string(metadata.GetUID())) </del> if string(patchBytes) == "{}" && !printObject { count++

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The dry run output listed all the resources that would be configured: deployments, HPAs, services, and an ingress: This was expected. However, it then listed all resources again (except for the HPAs) as being pruned: The config was then applied with: As expected, no resources were actually pruned. What you expected to happen: should actually display which resources are going to be pruned. How to reproduce it (as minimally and precisely as possible): a YAML file to with it: run + prune: should be listed as both configured and pruned it again with pruning: that the deployment is configured but not pruned, even though the dry run said it would be. Anything else we need to know?: Was trying to write a devops script that gave a warning before any resources would be pruned. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): (Lubuntu 18.04) Kernel (e.g. ):Install tools: Others:
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
I can reproduce it, and i will try to fix it.
Change:
}) <del> It("should be able to discover a non-local federated service", func() { </del> <ins> PIt("should be able to discover a non-local federated service", func() { </ins> fedframework.SkipUnlessFederated(f.ClientSet) nsName := f.FederationNamespace.Name

Discussion:
This has surfaced in Ingress and Service e2e tests that manipulate DNS entries. The service controller queries the managed dns entry, thinks that the CNAME doesn't exist and adds a new one. However, clouddns says (through a 409) that the entry already exists. Error message aside, the control flow within the service controller's endpoint_helper prevents a service from being deleted. It's unclear at this point whether there's a race condition. I doubt it given the amount of logging that happens showing that there is no concurrent CNAME entry being created. cc Have you seen this in your refactoring?
Hi I used CoreDNS for most of my testing for service controller refactoring and i did not notice these errors. my local test environment is slightly different than the CI environment. i would do more tests on this issue using CoreDNS and would confirm, if it is an issue also in coredns or just google-clouddns.
If you're not still working on this, please unassign yourself and we'll try to find someone else. Thanks.
This issue was labelled only for sig/multicluster and is thus moved over to kubernetes/federation. If this does not seem to be right, please reopen this and notify us /close
Change:
framework.ExpectNoError(err) framework.ExpectEqual(updatedStatus.Status.LoadBalancer, statusToUpdate.Status.LoadBalancer, fmt.Sprintf("updated object expected to have updated loadbalancer status %#v, got %#v", statusToUpdate.Status.LoadBalancer, updatedStatus.Status.LoadBalancer)) <ins> ginkgo.By("get /status") ingResource := schema.GroupVersionResource{Group: "networking.k8s.io", Version: ingVersion, Resource: "ingresses"} gottenStatus, err := f.DynamicClient.Resource(ingResource).Namespace(ns).Get(context.TODO(), createdIngress.Name, metav1.GetOptions{}, "status") framework.ExpectNoError(err) statusUID, _, err := unstructured.NestedFieldCopy(gottenStatus.Object, "metadata", "uid") framework.ExpectNoError(err) framework.ExpectEqual(string(createdIngress.UID), statusUID, fmt.Sprintf("createdIngress.UID: %v expected to match statusUID: %v ", createdIngress.UID, statusUID)) </ins> // Ingress resource delete operations ginkgo.By("deleting") err = ingClient.Delete(context.TODO(), createdIngress.Name, metav1.DeleteOptions{})

Discussion:
[ ] two weeks soak start date : testgrid-link [ ] two weeks soak end date : [ ] test promotion pr : kubernetes/kubernetes#? It was picked up in APISnoop that an untested endpoint was promoted from Beta to GA. PR ingress: promote CRUD API tests for v1 to conformance covered the Ingress life cycle tests, but readNetworkingV1NamespacedIngressStatus was missed. According to this APIsnoop readNetworkingV1NamespacedIngressStatus endpoint is untested. ginkgo.By("get /status") ingResource := schema.GroupVersionResource{Group: "", Version: ingVersion, Resource: "ingresses"} gottenStatus, err := f.DynamicClient.Resource(ingResource).Namespace(ns).Get(context.TODO(), createdIngress.Name, metav1.GetOptions{}, "status") framework.ExpectNoError(err) statusUID, _, err := unstructured.NestedFieldCopy(gottenStatus.Object, "metadata", "uid") framework.ExpectNoError(err) framework.ExpectEqual(string(createdIngress.UID), statusUID, fmt.Sprintf("createdIngress.UID: %v expected to match statusUID: %v ", createdIngress.UID, statusUID)) ''' List endpoints hit by the test: readNetworkingV1NamespacedIngressStatus endpoint If this test get merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
Duplicate of
/reopen Merged /assign Ready for creation of Promotion PR
Reopened this issue. <detailsIn response to : /reopen Merged /assign Ready for creation of Promotion PR 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
Code change was a bug fix in a Merged conformance test. The correction should not require Promotion. /close
Closing this issue. <detailsIn response to : Code change was a bug fix in a Merged conformance test. The correction should not require Promotion. /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
Change:
var ( vmssNameSeparator = "_" <ins> vmssKey                 = "k8svmssKey" </ins> vmssVirtualMachinesKey  = "k8svmssVirtualMachinesKey" availabilitySetNodesKey = "k8sAvailabilitySetNodesKey" availabilitySetNodesCacheTTL = 15 * time.Minute <ins> vmssTTL                      = 10 * time.Minute </ins> vmssVirtualMachinesTTL       = 10 * time.Minute )

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: Recently we upgraded our cluster from 1.14.4 to 1.14.7. Then we started to observe tons of following errors: I guess the cause may be related to this line which was introduced recently: As we have hundreds of services with LoadBalancer type, and we also enable cluster-autoscaler, the nodes list change very often. For each service, there will be one call to GetScaleSet. The quota will be exhausted quickly. When fails, new nodes created by cluster-autoscaler will lose connectivity to load balancer. What you expected to happen: Kubernetes should not hit VMSS throttling threshold. How to reproduce it (as minimally and precisely as possible): a cluster with aks-engine. Use VMSS. 200 services with LoadBalancer type. up VMSS to 50 nodes down VMSS to 60 nodes scaling up and down VMSS Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.7 Cloud provider or hardware configuration: Azure, VMSS OS (e.g: ): Ubuntu Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure
I create a PR to mitigate the issue.
do we have a rough num about how this PR would mitigate this issue? looks like we need to cherry-pick this PR to old releases. it's better if we have a rough estimation.
The revised version of code calls instead of azure API. The cache refreshes itself every 10 min. I believe this will solve the throttling issue.
I believe we're being affected by this. Apart from getting the - when creating our to use a pre-configured Azure Public IP, the ingress appears to be getting a different IP each time
Thank you all!
The PR is merged. Does your issue remain?

pls cherry-pick that fix to old release, thanks
Cherry picked to release 1.14-1.16
I’ll retry today and let you know Wysłane z iPhone'a
Issue returned in K8S 1.15.4 Warning UpdateLoadBalancerFailed service/nginx-ingress-controller Error updating load balancer with new hosts map[<nodes names]: [EnsureHostInPool(ingress/nginx-ingress-controller): backendPoolID(/subscriptions/<subscription/resourceGroups/<rg/providers/Microsoft.Network/loadBalancers/<rg/backendAddressPools/<rg) - failed to ensure host in pool: "azure - cloud provider rate limited(read) for operation:VMSSGet", EnsureHostInPool(ingress/nginx-ingress-controller):