jiebi/CodeConvo huggingface dataset:
Change:
if err := Convert_v1_AuthInfo_To_api_AuthInfo(&curr.AuthInfo, newAuthInfo, s); err != nil { return err } <ins> if *out == nil { *out = make(map[string]*api.AuthInfo) } </ins> if (*out)[curr.Name] == nil { (*out)[curr.Name] = newAuthInfo } else {

Discussion:
What happened: I have a test case: This behaves different with different client-go versions. With , the test passes. This is using in with in With , this test panics. This is using in with in Panic logs: Basically it its creating an object to decode into, and this object has some maps. These are set to nil, so when we try to populate them we get a panic. What you expected to happen: Behavior remains the same as previous release, or at least have some alternative that works here? How to reproduce it (as minimally and precisely as possible): I pasted the test above that reproduces this. This can be reproduced with a project with just that file, and a file with only client-go. Using go 1.13
/sig api-machinery
/assign
Change:
return fmt.Errorf("Failed to delete destination for service %v, service not found", key.String()) } dests := f.Destinations[key] <del> var i int for i = range dests { if dests[i].Equal(dest) { </del> <ins> exist := false for i := range dests { if toRealServerKey(dests[i]).String() == toRealServerKey(dest).String() { // Delete one element f.Destinations[key] = append(f.Destinations[key][:i], f.Destinations[key][i+1:]...) exist = true </ins> break } } // Not Found <del> if i >= len(f.Destinations[key]) { </del> <ins> if !exist { </ins> return fmt.Errorf("Failed to delete real server for service %v, real server not found", key.String()) } <del> // Delete one element f.Destinations[key] = append(f.Destinations[key][:i], f.Destinations[key][i+1:]...) </del> return nil }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: IPVS real server can't be right deleted in FakeIPVS for ipvs testing. What you expected to happen: When delete ipvs real server, we can't give the weight information, so we can't use deep equal in .
/sig network /area ipvs
/kind bug
Change:
}, expectedNeedsUpdate: true, }, <ins> { testName: "If service IPFamilies from single stack to dual stack", updateFn: func() { protocol := "http" oldSvc = &v1.Service{ ObjectMeta: metav1.ObjectMeta{ Name:      "tcp-service", Namespace: "default", }, Spec: v1.ServiceSpec{ Ports: []v1.ServicePort{{ Port:        80, Protocol:    v1.ProtocolTCP, TargetPort:  intstr.Parse("22"), AppProtocol: &protocol, }}, IPFamilies: []v1.IPFamily{v1.IPv4Protocol}, Type:       v1.ServiceTypeLoadBalancer, }, } newSvc = oldSvc.DeepCopy() newSvc.Spec.IPFamilies = []v1.IPFamily{v1.IPv4Protocol, v1.IPv6Protocol} }, expectedNeedsUpdate: true, }, { testName: "If service IPFamilies from dual stack to single stack", updateFn: func() { protocol := "http" oldSvc = &v1.Service{ ObjectMeta: metav1.ObjectMeta{ Name:      "tcp-service", Namespace: "default", }, Spec: v1.ServiceSpec{ Ports: []v1.ServicePort{{ Port:        80, Protocol:    v1.ProtocolTCP, TargetPort:  intstr.Parse("22"), AppProtocol: &protocol, }}, IPFamilies: []v1.IPFamily{v1.IPv4Protocol, v1.IPv6Protocol}, Type:       v1.ServiceTypeLoadBalancer, }, } newSvc = oldSvc.DeepCopy() newSvc.Spec.IPFamilies = []v1.IPFamily{v1.IPv4Protocol} }, expectedNeedsUpdate: true, }, { testName: "If service IPFamilies not change", updateFn: func() { protocol := "http" oldSvc = &v1.Service{ ObjectMeta: metav1.ObjectMeta{ Name:      "tcp-service", Namespace: "default", }, Spec: v1.ServiceSpec{ Ports: []v1.ServicePort{{ Port:        80, Protocol:    v1.ProtocolTCP, TargetPort:  intstr.Parse("22"), AppProtocol: &protocol, }}, IPFamilies: []v1.IPFamily{v1.IPv4Protocol}, Type:       v1.ServiceTypeLoadBalancer, }, } newSvc = oldSvc.DeepCopy() }, expectedNeedsUpdate: false, }, </ins> } controller, _, _ := newController()

Discussion:
Currently, when loadbalancer service's ipFammilies updatedservice controller will ignore this event. That means cloud provider can't update ipv4/ipv6 backend. So, I'm thinking service controller need add watching 'service's ipFammilies updated' event, It'd be important for cloud provider update dual-stack backend. code at Our load balancer supports dual-stack. When the services in the cluster are updated from IPv4 to IPv6(same ipv6-ipv4ipv4-ipv4/ipv6), it is expected that the cloud provider can perceive this event and update the IPv4/IPv6 address to the backend of the load balancer. /sig cloud-provider /area cloudprovider
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
yeah, that is right, the logic need to be adapted /kind bug /sig network /sig cloud-provider
Change:
volumePaths: []string{ filepath.Join("pod1", "volumes", "missing-plugin", "pvc-abcdef"), }, <del> expectedVolumesNeedReportedInUse:    []string{}, </del> expectedVolumesNeedDevicePath:       []string{}, expectedVolumesFailedReconstruction: []string{"pvc-abcdef"}, },

Discussion:
remove and was introduced in to fix This is to overcome the situation that volume is to DSW at first and then deleted before it is to ASW, which causes mounted volume neither in DSW nor ASW and won't execute unmount/detach: The reason the volume cannot be to ASW in time is , which is . However, there is another PR also solved the issue. What it did is to check whether ASW already has the volume before deleting it from DSW, this makes sure that volume can be detached/unmounted after it is deleted from DSW. I suggest that we can keep the second solution and remove related code to make the reconstruction process and reconcile loop cleaner?
/sig storage
cc
Should I proceed with this issue? Your guidance is appreciated.
I think we'd better wait for the feedback from
cc
Sorry for a late reply. This is how behind we are with reviews :-(. Reading Now that is on by default, it reconstructs volumes first and always puts them to ASW, it should never happen that a reconstructed volume is in DSW and not in ASW, right? So we can remove easily. I would not be so sure without , because the code is 5 years old and who knows all the implications. You could be right though, it may not be necessary there too.
/triage accepted
/assign
Change:
Expect(rsList.Items[0].Spec.Template.Spec.Containers[0].Image).To(Equal(deploy.Spec.Template.Spec.Containers[0].Image)) By("Deleting the first deployment") <del> stopDeployment(c, f.Client, ns, deploy.Name) </del> <ins> stopDeploymentOverlap(c, f.Client, ns, deploy.Name, deployOverlapping.Name) </ins> // Wait for overlapping annotation cleared By("Waiting for the second deployment to clear overlapping annotation")

Discussion:
https://k8s- Failed: [] Deployment overlapping deployment should not fight with each other {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment overlapping deployment should not fight with each other {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment overlapping deployment should not fight with each other {Kubernetes e2e suite} Happened on a presubmit run in .
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Deployment overlapping deployment should not fight with each other {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment overlapping deployment should not fight with each other {Kubernetes e2e suite}
Looking
Flakes happened when stopping overlapping deployments at clean up step.
You probably need to move the check before the deletionTimestamp check. Just make sure that observedGeneration is updated for the first case.
Because the deployments are overlapping, when deleting one deployment and determining if its RSes are deleted, there might be a race when the other deployment creates an RS
[FLAKE-PING] This flaky-test issue would love to have more attention.
Change:
// certain minimum of nodes are checked for feasibility. This in turn helps // ensure a minimum level of spreading. minFeasibleNodesToFind = 100 <ins> // minFeasibleNodesPercentageToFind is the minimum percentage of nodes that // would be scored in each scheduling cycle. This is a semi-arbitrary value // to ensure that a certain minimum of nodes are checked for feasibility. // This in turn helps ensure a minimum level of spreading. minFeasibleNodesPercentageToFind = 5 </ins> ) // FailedPredicateMap declares a map[string][]algorithm.PredicateFailureReason type.

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Kubernetes scheduler has that specifies what percentage of the cluster nodes should be scored in each scheduling cycle. The scheduler stops scanning more nodes once that many nodes are found feasible for running the pod under consideration. The default value of this config option is 50 (for 50%). We should let the scheduler determine this value based on the size of the cluster when this config option is not provided. I'd propose this formula for finding the percentage: . This is a linear formula that gives us 50 when the cluster size is 100 nodes and 10 for a 5000 node cluster. The scheduler already has a lower bound of 50 nodes per scheduling cycle. As a part of this change, we should also add a 5% lower bound for the formula (If the result of the formula is below 5, we should return 5). Why is this needed: To improve scheduler performance in large clusters. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature /sig scheduling
/assign /remove-help
/assign wgliang
Thanks
Change:
expectFatal:  false, expectDelete: false, }, <ins> { description:                "fail to list pods", node:                       node, expected:                   cordonedNode, pods:                       []corev1.Pod{rsPod}, replicaSets:                []appsv1.ReplicaSet{rs}, args:                       []string{"node"}, expectFatal:                true, expectDelete:               true, failUponEvictionOrDeletion: true, }, </ins> } testEviction := false

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: kubectl drain crashed with panic when apiserver connection disappeared while there were pods that couldn't be evicted/deleted (sorry, the problem is a bit hard to reproduce and the log was lost) What you expected to happen: kubectl drain should exit with a proper error message How to reproduce it (as minimally and precisely as possible): Try kubectl drain multiple times, interrupting the connection during eviction/deletion Anything else we need to know?: The here can be in case if returns an error, and will panic upon accessing : This causes the c Environment: Kubernetes version (use ): The problem is present as of but is also present in earlier versions (I have a fix for this bug)
/priority important-longterm /sig cli
Change:
// Returns an interactive clientConfig if the password flag is enabled, // or a non-interactive clientConfig otherwise. func (f *ConfigFlags) ToRawKubeConfigLoader() clientcmd.ClientConfig { <ins> if f.usePersistentConfig { return f.toRawKubePersistentConfigLoader() } return f.toRawKubeConfigLoader() } func (f *ConfigFlags) toRawKubeConfigLoader() clientcmd.ClientConfig { </ins> loadingRules := clientcmd.NewDefaultClientConfigLoadingRules() // use the standard defaults for this client command // DEPRECATED: remove and replace with something more accurate

Discussion:
/kind bug What happened: takes ~11 seconds when there are thousands of CRDs and is around 28KiB. logs the following message once per resource: Removing unnecessary entries from reduces the runtime by around ten seconds. What you expected to happen: only parses once, and therefore doesn't run unnecessarily slowly. How to reproduce it (as minimally and precisely as possible): shows the config being loaded multiple times (assuming you have multiple pods in the current cluster). Alternatively, add 10-15 clusters to and create ~3000 of a cheap resource (eg custom resources or empty config maps). Run on this resource and observe that it is unnecessarily slow. Anything else we need to know?: I've created a CPU profile using the latest CI build of kubectl, which shows ~12 seconds being spent in . Environment: Kubernetes version (use ): v1.12.1 (also Cloud provider or hardware configuration: GKE or minikube --vm-driver=none OS (e.g. from /etc/os-release): Debian Buster-like Kernel (e.g. ): 4.17.0
/sig cli
/assign
Same problem here. I have less resources but more contexts in my kubeconfig file. With 90 pods and ~300 contexts in the kubeconfig it also takes ~10 seconds for a simple kubectl get pods Note: I tried it with kubectl: 1.11.0, 1.12. With kubectl 1.10.5 the kubeconfig was loaded only once.
I'm unable to reproduce this as of the latest master. My kubeconfig is only loaded 4 times, no matter how many resources are loaded.
When I try a kubectl v1.13.0-alpha.3 against unfortunately a 1.9.11 Kubernetes Cluster I still have the problem: `
Maybe the bug is Linux-only? Presumably the kubeconfig location is different on different platforms, so maybe it has a different code path. I can repro on latest master:
I filed to fixed this. You can try to help validate it. Thanks.
Works for me, thanks!
Change:
assert.Equal(t, owns, c.expected, "TestCase[%d]: %s", i, c.desc) } } <ins> func TestGetServiceTags(t *testing.T) { tests := []struct { desc     string service  *v1.Service expected []string }{ { desc:     "nil should be returned when service is nil", service:  nil, expected: nil, }, { desc:     "nil should be returned when service has no annotations", service:  &v1.Service{}, expected: nil, }, { desc: "single tag should be returned when service has set one annotations", service: &v1.Service{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ ServiceAnnotationAllowedServiceTag: "tag1", }, }, }, expected: []string{"tag1"}, }, { desc: "multiple tags should be returned when service has set multi-annotations", service: &v1.Service{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ ServiceAnnotationAllowedServiceTag: "tag1, tag2", }, }, }, expected: []string{"tag1", "tag2"}, }, { desc: "correct tags should be returned when comma or spaces are included in the annotations", service: &v1.Service{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ ServiceAnnotationAllowedServiceTag: ", tag1, ", }, }, }, expected: []string{"tag1"}, }, } for i, c := range tests { tags := getServiceTags(c.service) assert.Equal(t, tags, c.expected, "TestCase[%d]: %s", i, c.desc) } } </ins>

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: Azure cloud provider has a limited support for service tags by annotations: But according to , there are actually much more service tags than this list. Hence, errors would happen if the service tag is not included in the above list. What you expected to happen: Azure cloud provider should support all service tags from Azure. 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: /kind bug /sig azure /priority important-soon
/assign
Change:
// A maxItems value of -1 means no limit. func NewTimedStore(age time.Duration, maxItems int) *TimedStore { return &TimedStore{ <del> buffer:   make([]timedStoreData, 0), </del> <ins> buffer:   make(timedStoreDataSlice, 0), </ins> age:      age, maxItems: maxItems, }

Discussion:
I have some reports of a Node reporting a a resource capacity for cpu as a negative value. Any idea why cpu could report as a negative value? Is this an expected normal outcome? In its current state, it prevents any pods from being scheduled to that Node. Tips on how to debug further are appreciated. - any ideas?
Can you check machineInfo on Cadvisor or kubelet on the node?
a.k.a:
It is a bug in cAdvisor side. I am assigning it to you :-)
here is contents of /proc/cpuinfo Pertinent pieces of a log:
Machine is AWS instance if that matters....
We build the topology from system/cpu info. I think we can return partial topology information and ignore caches if its not present. This isn't a recent change though. Is it happening on just a single machine? I'll file a cAdvisor issue.
Can you link the referenced issue once created?
Re-assigning to since he's working on google/cadvisor
Could be this was caused by getting a Node on EC2 with old hypervisor, and I am the first victim...
That sounds likely. Most of the cache information is there in /proc/cpuinfo. So looks like the sysfs bits are disabled.
Can you try this cadvisor image on your machine and check /api/v1.3/machine output: sudo docker run  --volume=/:/rootfs:ro  --volume=/var/run:/var/run:rw  --volume=/sys:/sys:ro  --volume=/var/lib/docker/:/var/lib/docker:ro  --publish=8080:8080  --detach=true  --name=cadvisor  jnagal/cadvisor:canary
hmm
ah, selinux :( You'll need to run it with --privileged, I think. who's been dealing with it.
No luck with --privileged either on this box...
This has to do with SELinux, I think we had to disable it for this to work (some of our mounts are being denied). We're working on a better solution... This is not a problem in Kubernetes since we don't run Kubelet/cAdvisor in a Docker container.
ok, unfortunately, i have managed to kill docker on the box in question, and i cannot get the daemon to restart right now so I am not sure when that box will be available to debug against again.

I can provide an environment with a similar issue if required.
The fix is checked in to head. Can you build the binary and try?
Change:
var outputObj runtime.Object obj := info.Object <del> if o.dryRunStrategy == cmdutil.DryRunClient || o.local { </del> <ins> if o.dryRunStrategy == cmdutil.DryRunClient || o.local || o.list { </ins> if err := o.updateAnnotations(obj); err != nil { return err }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : add --list option to kubectl annotate command Why is this needed: like kubectl label commandshow annotations quickly
/sig cli These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/assign
Change:
} }() } <del> // unhold all the calls with the same namespace handler.GetLimitRanges(attributes) calls, that have to be aggregated unhold <- struct{}{} go func() { unhold <- struct{}{} }() </del> // and here we wait for all the goroutines wg.Wait() // since all the calls with the same namespace will be holded, they must be catched on the singleflight group, // There are two different sets of namespace calls // hence only 2 <del> if count != 2 { t.Errorf("Expected 1 limit range, got %d", count) </del> <ins> if testCount != 1 { t.Errorf("Expected 1 limit range call, got %d", testCount) } if test1Count != 1 { t.Errorf("Expected 1 limit range call, got %d", test1Count) </ins> } // invalidate the cache handler.liveLookupCache.Remove(attributes.GetNamespace()) <del> go func() { // unhold it is blocking until GetLimitRanges is executed unhold <- struct{}{} }() </del> _, err = handler.GetLimitRanges(attributes) if err != nil { t.Errorf("unexpected error: %v", err) } <del> close(unhold) if count != 3 { t.Errorf("Expected 2 limit range, got %d", count) </del> <ins> if testCount != 2 { t.Errorf("Expected 2 limit range call, got %d", testCount) } if test1Count != 1 { t.Errorf("Expected 1 limit range call, got %d", test1Count) </ins> } }

Discussion:
pull-kubernetes-unit /cc /sig scalability
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
In local tests, he always passes, so I'll see if the problem is caused by the environment
If the lru cache exceeds 30 seconds, the cache will be invalidated, which will lead to unit test errors, and the problem will run normally again after retesting.
After I manually reduce an unhold <- struct{}{}, the same problem occurs, so it seems that the problem is caused by the cache being invalidated for more than 30 seconds. If the test doesn't complete in 30 seconds, then this is probably a machine performance issue
stress will hang after about a minute in my local test.
/cc
The issue is being fixed
Change:
} // All volumes bound or matching PVs found for all unbound PVCs <del> glog.V(5).Info("All PVCs found matches for pod %v/%v, node %q", pod.Namespace, pod.Name, node.Name) </del> <ins> glog.V(5).Infof("All PVCs found matches for pod %v/%v, node %q", pod.Namespace, pod.Name, node.Name) </ins> return true, nil, nil }

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?: /assign What happened: Volume got bound to PV on node "kubernetes-minion-group-82c8" When the pod went back through scheduling, the predicate returned success for other nodes even though we should have updated the PV cache to point to the PVC: I think in , instead of continuing if the node affinity doesn't match, it should fail if the PV is prebound.
This causes two issues: On the second pass, the scheduler may choose a different node. Then in Assume/Bind volumes, we'll also prebind a second set of PVs. If the scheduler chose a different node on the second pass, and the PVCs became fully bound in between the predicates and assume volumes, then assume volumes will return success and the pod will get scheduled to the wrong node.
Change:
}, } <del> expectedCandidates := []*kubecontainer.ContainerStatus{pod.ContainerStatuses[2], pod.ContainerStatuses[1]} candidates := newPodContainerDeletor(&containertest.FakeRuntime{}, 1).getContainersToDeleteInPod("2", &pod) if !reflect.DeepEqual(candidates, expectedCandidates) { t.Errorf("expected %v got %v", expectedCandidates, candidates) </del> <ins> testCases := []struct { containersToKeep           int expectedContainersToDelete []*kubecontainer.ContainerStatus }{ { 0, []*kubecontainer.ContainerStatus{pod.ContainerStatuses[3], pod.ContainerStatuses[2], pod.ContainerStatuses[1]}, }, { 1, []*kubecontainer.ContainerStatus{pod.ContainerStatuses[2], pod.ContainerStatuses[1]}, }, { 2, []*kubecontainer.ContainerStatus{pod.ContainerStatuses[1]}, }, } for _, test := range testCases { candidates := getContainersToDeleteInPod("4", &pod, test.containersToKeep) if !reflect.DeepEqual(getContainersToDeleteInPod("4", &pod, test.containersToKeep), test.expectedContainersToDelete) { t.Errorf("expected %v got %v", test.expectedContainersToDelete, candidates) } </ins> } }

Discussion:
Kubelet evicts pods whenever there is memory or disk pressure. It marks the pods as to evict them. To help with reducing disk pressure, kubelet should delete all containers belonging to pods right away. This will result in loss of logs. In the future, we can copy out logs from dead containers before deleting them. Logs can be rotated separately from dead containers. IMO, this feature is required for disk usage based evictions to work reliably in kubelet.