jiebi/CodeConvo huggingface dataset:
Change:
testableResources := etcd.GetEtcdStorageDataForNamespace(f.Namespace.Name) for _, group := range apiGroups { <ins> // This limits the scope of this test to exclude CRDs. This // assumes that CRDs will not have a .k8s.io group and will have // a . in their name. if !strings.Contains(group.GroupVersion, ".k8s.io") && strings.Contains(group.GroupVersion, ".") { continue } </ins> for _, resource := range group.APIResources { if !verbsContain(resource.Verbs, "get") || ignoredResources[resource.Kind] || strings.HasPrefix(resource.Name, "e2e-test") { continue

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce-master-scale-correctness Which test(s) are failing: [sig-cli] Kubectl client kubectl get output should contain custom columns for each resource Since when has it been failing: 11/6 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: n/a /sig cli /sig scalability /cc
The label(s) cannot be applied. These labels are supported: <detailsIn response to : <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --gce-master-scale-correctness [sig-cli] Kubectl client kubectl get output should contain custom columns for each resource 11/6 https://k8s- Anything else we need to know: n/a /sig scalability /cc 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
Doesn't seem to be scale-related - failed for me the same way in the presubmit:
- do we run correctness test in smaller scale (so we can detect whether failures are scale related or not)? I can't find them on neither https://k8s- nor https://k8s- dashboards.
This is a new test that seem to be flaky at head: - seems that you this in Can you please take a look?
/assign
/reopen Let's wait for the test to pass /assign
Reopened this issue. <detailsIn response to : /reopen /assign 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
That seems to be creating one of every object from the etcd data test in an e2e test. The failing object looks like a node object, which is likely getting deleted by the Node controller as soon as it is created.
opened to skip nodes for this test
/reopen The job is not green
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
failed test run started from a commit prior to the fix merging ( started from ) /close
Closing this issue. <detailsIn response to : failed test started from a commit prior to the fix merging ( started from ) 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:
} } <ins> func TestRootSelfLink(t *testing.T) { storage := map[string]rest.Storage{} simpleStorage := GetWithOptionsRootRESTStorage{ SimpleTypedStorage: &SimpleTypedStorage{ baseType: &genericapitesting.SimpleRoot{}, // a root scoped type item: &genericapitesting.SimpleRoot{ ObjectMeta: metav1.ObjectMeta{Name: "foo"}, Other:      "foo", }, }, takesPath: "atAPath", } storage["simple"] = &simpleStorage handler := handle(storage) server := httptest.NewServer(handler) defer server.Close() resp, err := http.Get(server.URL + "/" + prefix + "/" + testGroupVersion.Group + "/" + testGroupVersion.Version + "/simple/foo") if err != nil { t.Fatalf("unexpected error: %v", err) } if resp.StatusCode != http.StatusOK { t.Errorf("Unexpected status: %d, Expected: %d, %#v", resp.StatusCode, http.StatusOK, resp) body, err := ioutil.ReadAll(resp.Body) if err != nil { t.Fatalf("unexpected error: %v", err) } t.Logf("Data: %s", string(body)) } var out genericapitesting.SimpleRoot if _, err := extractBody(resp, &out); err != nil { t.Fatalf("unexpected error: %v", err) } if out.SelfLink != "/"+prefix+"/"+testGroupVersion.Group+"/"+testGroupVersion.Version+"/simple/foo" { t.Errorf("unexpected self link: %#v", out) } } </ins> func TestMetadata(t *testing.T) { simpleStorage := &MetadataRESTStorage{&SimpleRESTStorage{}, []string{"text/plain"}} h := handle(map[string]rest.Storage{"simple": simpleStorage})

Discussion:
Bug report Kubernetes version Client Version: version.Info{Major:"1", Minor:"5+", GitVersion:"v1.5.0-beta.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-24T22:35:03Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5+", GitVersion:"v1.5.0-beta.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-24T22:30:23Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"} When you curl the api you get a list of third party resources, however their selflinks are missing a forward slash:
fixed with , you may take a look.
This looks like it affects root scoped resources in general -- both custom ones (e.g. ServiceCatalog brokers, as noted in kubernetes-incubator/service-catalog) and "built-in" ones, like namespaces and nodes:
cc
Change:
cmdutil.AddFilenameOptionFlags(cmd, options, usage) cmd.Flags().StringP("selector", "l", "", "Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2)") cmd.Flags().Bool("all-namespaces", false, "If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace.") <del> cmd.Flags().BoolVar(&describerSettings.ShowEvents, "show-events", true, "If true, display events related to the described object.") </del> <ins> cmd.Flags().BoolVar(&describerSettings.ShowEvents, "show-events", describerSettings.ShowEvents, "If true, display events related to the described object.") </ins> cmdutil.AddInclude3rdPartyFlags(cmd) cmdutil.AddIncludeUninitializedFlag(cmd) return cmd

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 /sig cli What happened: Currently xxxOptions does not get bound as default value for some flags, which may bring in potential risks/bugs for some commands. Such as , Here the default value for flag will always be an empty string, regardless of the actual value of . Already discussed this potential bug with in Slack. This issue is used to track those cleanup items. [x] flag value bindings for kubectl attach/convert/delete/drain/edit/exec commands ( ) [x] flag value bindings for kubectl apply commands ( ) [x] flag value bindings for kubectl label/patch/taint/top commands ( ) [x] flag value bindings for kubectl create/get/set commands () [x] kubectl: flag value bindings for common utils ( )
/assign
/cc
This is a really good bit of cleanup and I'm glad to see the pulls.
/priority important-longterm
/reopen
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 7 days, the issue will be moved out of the v1.11 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners; move out of the milestone after 1 attempt. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/close All the fixes have been merged.
Thanks
Change:
}, expectedErr: fmt.Errorf("failed to find a primary nic for the vm. vmname="vm""), }, <ins> { description:       "GetPrimaryInterfaceID should report an error if there's no network interface on the VMSS VM", existedInterfaces: []compute.NetworkInterfaceReference{}, expectedErr:       fmt.Errorf("failed to find the network interfaces for vm vm"), }, </ins> } for _, test := range testCases {

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: kube-controller-manager panic when network interfaces for Azure VMSS are null. This happens when Azure cloud provider tried to get IP address for VMSS VM: What you expected to happen: kube-controller-manager should report an error instead of panic. How to reproduce it (as minimally and precisely as possible): Scale cluster nodes up and down frequently. Anything else we need to know?: /kind bug /area provider/azure Environment: Kubernetes version (use ): 1.15+ Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /assign
Change:
if state.SkipFilterPlugins.Has(pl.Name()) { continue } <del> metrics.PluginEvaluationTotal.WithLabelValues(pl.Name(), metrics.Filter, f.profileName).Inc() </del> if status := f.runFilterPlugin(ctx, pl, state, pod, nodeInfo); !status.IsSuccess() { if !status.IsUnschedulable() { // Filter plugins are not supposed to return any status other than

Discussion:
We observed degradation in scheduling throughput, putting it under 100 pods/s. Respective pprof of kube-scheduler points it to ! /sig scheduling /kind regression 100 pods/node n/a No response <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
/cc
/sig scalability
Thanks for noticing it /assign
just to confirm this bug is present only in 1.27 ( introduced with pluginevaluationtotal metric) , isn't it ?
Exactly, 1.27+ (so the current master as well) to be specific.
Change:
"printers.go", ], deps = [ <del> "//cmd/kubeadm/app/apis/kubeadm:go_default_library", </del> "//federation/apis/federation:go_default_library", "//federation/apis/federation/v1beta1:go_default_library", "//federation/client/clientset_generated/federation_clientset:go_default_library",

Discussion:
/kind bug What happened: doesn't show role Workaround: What you expected to happen: According to and How to reproduce it (as minimally and precisely as possible): I just deployed a multi master kubernetes environment with kops: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS Install tools: kops, terraform
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 . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig cli
I don't think this is a bug. The node role label is not used by kubeadm anymore. Related codes have been changed in by
Hi Thanks for the quick reply I'm actually using the as you can see in the workaround above. I'm not using kubeadm role label.
Your favorite topic came up again. Hi I do think this is a bug. As said, kubectl shouldn't show anything based on the old kubeadm master label, but it should probably on the label, but absolutely on the label. cc as you have opinions on this as well cc
Change:
c.versionSupported = supported if !supported { <del> return fmt.Errorf("version %s not supported", verToStr(ver)) </del> <ins> return fmt.Errorf( "CSI Driver does not support version %s. Instead it supports versions %s", verToStr(ver), versToStr(vers)) </ins> } glog.V(4).Info(log("version %s supported", verToStr(ver)))

Discussion:
/kind bug What happened: When a CSI driver reports a version of the CSI spec which does not match that stored in Kubernetes, Kubernetes prints the following message: What you expected to happen: Message should be: How to reproduce it (as minimally and precisely as possible): Use a CSI driver that reports version 0.0.0. Then deploy an application pod with a PVC from this driver. Application pod description will show the actual message above. Environment: Kubernetes version (use ): 1.9.1
/sig storage
/assign lpabon
hi, I can help fix that.
I did not see your PR until after I submitted.
Change:
lb.OnUpdate([]api.Endpoints{ {JSONBase: api.JSONBase{ID: "echo"}, Endpoints: []string{net.JoinHostPort("127.0.0.1", port)}}}) <del> p := NewProxier(lb) </del> <ins> p := NewProxier(lb, "127.0.0.1") </ins> proxyPort, err := p.addServiceOnUnusedPort("echo") if err != nil {

Discussion:
kube-proxy listens on all ports, but should be configurable. create a flag to specify which interface to listen on. Thanks for finding this bug.
For context, some providers apparently do external IPs by having a whole interface that gets 1:1 NAT without any firewalling. We do not want service ports on those interfaces. , Brian Ketelsen wrote:
Change:
} clientRuleAnnotation := fmt.Sprintf("%s=%s", NLBClientRuleDescription, lbName) healthRuleAnnotation := fmt.Sprintf("%s=%s", NLBHealthCheckRuleDescription, lbName) <del> vpcCIDRs, err := c.getVpcCidrBlocks() if err != nil { return err } </del> for sgID, sg := range clusterSGs { sgPerms := NewIPPermissionSet(sg.IpPermissions...).Ungroup() if desiredSGIDs.Has(sgID) { <del> if err := c.updateInstanceSecurityGroupForNLBTraffic(sgID, sgPerms, healthRuleAnnotation, "tcp", healthCheckPorts, vpcCIDRs); err != nil { </del> <ins> if err := c.updateInstanceSecurityGroupForNLBTraffic(sgID, sgPerms, healthRuleAnnotation, "tcp", healthCheckPorts, subnetCIDRs); err != nil { </ins> return err } if err := c.updateInstanceSecurityGroupForNLBTraffic(sgID, sgPerms, clientRuleAnnotation, clientProtocol, clientPorts, clientCIDRs); err != nil {

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: For each NLB created, K8s creates an ingress rule on the node group's security group for each port exposed for each CIDR attached to the VPC to allow health checks to succeed. AWS limits the number of rules per security group to 60 by default. This quota is adjustable but multiplied by the quota for security groups per network interface cannot exceed 1000. I have a VPC with 16 CIDR blocks attached to it and a quota for rules per security group set to 80. Each NLB created adds 18 new rules (16 for Health Check, 1 for Client, and 1 for MTU) to the node group's security groups. This high number of unnecessary rules created makes it impossible to create more than 4 NLBs per node group (if each one has a single port exposed). What you expected to happen: For the health check to succeed, the NLB must be able to ping the node port for the service on the cluster's node group. So the node group's security group just needs an inbound rule for each ENI of the NLB, making the number of rules necessary on the cluster's node group directly proportional to the number of AZs the NLB is configured. How to reproduce it (as minimally and precisely as possible): Create a VPC on AWS with 8 CIDRs attached to it; Create a K8s Cluster; Create a Network Load Balancer with 6 ports exposed; If the default quota of rules per security group has not been changed, the NLB creation will fail with RulesPerSecurityGroupLimitExceeded. 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 cloud-provider
/area provider/aws
Change:
return errors.Wrap(err, "unable to fetch CoreDNS current installed version and ConfigMap.") } <del> var hasCoreDNSMigrationFailed bool if IsCoreDNSConfigMapMigrationRequired(corefile) { </del> <ins> canMigrateCorefile, err := isCoreDNSVersionSupported(client) if err != nil { return err } corefileMigrationRequired, err := isCoreDNSConfigMapMigrationRequired(corefile, currentInstalledCoreDNSVersion) if err != nil { return err } if !canMigrateCorefile { klog.Warningf("the CoreDNS Configuration will not be migrated due to unsupported version of CoreDNS. " + "The existing CoreDNS Corefile configuration and deployment has been retained.") } if corefileMigrationRequired && canMigrateCorefile { </ins> if err := migrateCoreDNSCorefile(client, coreDNSConfigMap, corefile, currentInstalledCoreDNSVersion); err != nil { // Errors in Corefile Migration is verified during preflight checks. This part will be executed when a user has chosen // to ignore preflight check errors. <del> hasCoreDNSMigrationFailed = true </del> <ins> canMigrateCorefile = false </ins> klog.Warningf("the CoreDNS Configuration was not migrated: %v. The existing CoreDNS Corefile configuration has been retained.", err) if err := apiclient.CreateOrRetainConfigMap(client, coreDNSConfigMap, kubeadmconstants.CoreDNSConfigMap); err != nil { return err

Discussion:
What happened: Coredns failed to start in 1.17 deployment when it tried to retain a backed up Corefile with error message: Caddyfile via flag: open /etc/coredns/Corefile: no such file or directory What you expected to happen: Coredns starts normally with the backed-up Corefile How to reproduce it (as minimally and precisely as possible): Deploy a k8s 1.17 cluster and trigger coredns Corefile migration and make it fail. In our case, this was triggered in a three master -setup with 'old' method of running 'kubeadm init' for each master. Also the core-dns docker image used was tagged with '1.6.7-1', apparently causing the corefile migration version check to fail Anything else we need to know?: This seems to be caused by Both 'key' and 'path' are set to 'Corefile-backup' when this function is called. Should the 'path' always stay as 'Corefile' because that is where the container expects to find the config file? Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-02-16T17:51:57Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-02-16T17:47:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Custom deployment in Openstack environment OS (e.g: ): NAME="SLES" VERSION="15-SP1" VERSIONID="15.1" PRETTYNAME="SUSE Linux Enterprise Server 15 SP1" Kernel (e.g. ): 12.14-197.29-default Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig cluster-lifecycle
/assign
/area kubeadm
Change:
case desiredReplicas > scaleUpLimit: setCondition(hpa, autoscalingv2.ScalingLimited, v1.ConditionTrue, "ScaleUpLimit", "the desired replica count is increasing faster than the maximum scale rate") desiredReplicas = scaleUpLimit <ins> // Ensure that even if the scaleUpLimit is greater // than the maximum number of replicas, we only // set the max number of replicas as desired. if scaleUpLimit > hpa.Spec.MaxReplicas { setCondition(hpa, autoscalingv2.ScalingLimited, v1.ConditionTrue, "TooManyReplicas", "the desired replica count was more than the maximum replica count") desiredReplicas = hpa.Spec.MaxReplicas } </ins> case hpa.Spec.MinReplicas != nil && desiredReplicas < *hpa.Spec.MinReplicas: // make sure we aren't below our minimum var statusMsg string

Discussion:
/kind bug What happened: Since upgrading to Kube 1.7.6, I'm seeing my HPAs scale above it's maxReplicas. Because of this, it's rapidly creating pods, then terminating them, and repeat. What you expected to happen: I expected the HPA to never exceed maxReplicas. How to reproduce it (as minimally and precisely as possible): The HPA is logging: This seems to happen with the deployment's is low, and the HPA shows the deployment using more than 175% of it's If I increase the deployment's to better match actual usage (so that the deployment is using 120% or less), it occurs much less often. I deliberately set the low, to ensure services were over provisioned during the first roll out of HPA. I think the switch in after should be converted to individual if() statements. Anything else we need to know?: I am only setting on the deployment, not Looking at the code in , the version that worked (1.6.2) would only scale up and down by 1. The 1.7.6+ code is attempting to scale up by a larger amount. The new code seems appropriate in large clusters, where maxReplicas is in the tens or hundreds. It doesn't seem appropriate for clusters where maxReplicas is in the single digits. Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-21T19:06:19Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-14T06:36:08Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: AWS m4.2xlarge, 5 nodes OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: kops Version 1.7.0 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 . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Yeah, I think the bug is that we have a case short-circuiting another case.
I think your right - we are not checking whether . I submitted a diff with a fix and regression test.