jiebi/CodeConvo huggingface dataset:
Change:
<ins> { "spec": { "unwantedModules": { "github.com/go-kit/kit": "lots of transitive dependencies, see https://github.com/prometheus/common/issues/255", "github.com/go-openapi/analysis": "use k8s.io/kube-openapi/pkg/validation/spec", "github.com/go-openapi/spec": "use k8s.io/kube-openapi/pkg/validation/spec instead", "github.com/go-openapi/strfmt": "use k8s.io/kube-openapi/pkg/validation/strfmt instead", "github.com/go-openapi/validate": "use k8s.io/kube-openapi/pkg/validation/validate instead", "github.com/influxdata/influxdb1-client": "", "go.mongodb.org/mongo-driver": "", "k8s.io/klog": "we have switched to klog v2, so avoid klog v1", "rsc.io/quote": "refer to #102833", "rsc.io/sampler": "refer to #102833", "github.com/hashicorp/golang-lru": "", "github.com/hashicorp/hcl": "", "github.com/json-iterator/go": "refer to #105030", "github.com/spf13/viper": "refer to #102598", "github.com/go-bindata/go-bindata ": "refer to #99829" } }, "status": { "references": [ "github.com/go-kit/kit", "github.com/hashicorp/golang-lru", "github.com/hashicorp/hcl", "github.com/json-iterator/go", "github.com/spf13/viper" ] } } </ins>

Discussion:
Add a file to track dependencies we want to remove or avoid picking back up. Examples: (as opposed to ) {analysis,spec,strfmt,validate} () and () () Add a presubmit that uses to do the following: if any items in the "unwanted but still present" list are no longer present and prompts to move them to the "absent and not allowed" list if any items in the "absent and not allowed" list are present and fails. Dependency updates often reintroduce problematic dependencies that were previously dropped. /area code-organization /cc
/sig architecture /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig architecture /triage accepted /help 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 may help with it. /assign I checked the code, there is already a logic to check forbidden dependencies. can draw a go mod graph
yeah, that was sort of ad-hoc, and doesn't do the ratcheting bit we want (record a dependency we have but don't want, once we no longer use it, require moving it to the forbidden list)
Change:
totalMemory += container.Memory } } <del> percentageCPU := (totalCPU * 100) / resources.GetIntegerResource(node.NodeResources.Capacity, resources.CPU, 0) percentageMemory := (totalMemory * 100) / resources.GetIntegerResource(node.NodeResources.Capacity, resources.Memory, 0) </del> <ins> percentageCPU := calculatePercentage(totalCPU, resources.GetIntegerResource(node.NodeResources.Capacity, resources.CPU, 0)) percentageMemory := calculatePercentage(totalMemory, resources.GetIntegerResource(node.NodeResources.Capacity, resources.Memory, 0)) </ins> glog.V(4).Infof("Least Requested Priority, AbsoluteRequested: (%d, %d) Percentage:(%d%m, %d%)", totalCPU, totalMemory, percentageCPU, percentageMemory) return HostPriority{

Discussion:
HPA tests are currently failing in gke-large cluster suite: I did some debugging and the problem seems to be related to pod-nanny. Looking into logs from the last run: was first scheduled on the large node dedicated to it pod-nany updated heapster deployment then heapster was scheduled on the normal node (when it actually shouldn't fit) that point it was never updated by the pod nanny. that point, heapster started crashlooping (OOMing) [which in fact was expected in too small machine] So it's pretty clear that that pod-nanny changed the amount of resources to something smaller, which in fact it shouldn't.
Change:
incoming <- &copied } <del> var ( watchChannelHWM HighWaterMark ) </del> // translate pulls stuff from etcd, converts, and pushes out the outgoing channel. Meant to be // called as a goroutine. func (w *etcdWatcher) translate() {

Discussion:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
This is pretty much the same failure, that are happening in "gce-enormous" suite and we currently debugging them with The main reason of those failures is that we are terminating all watchers for a particular resource type from time to time, and some of them are actually causing a snowball effect. After more looking into it, my hypothesis is that our machinery for aggregating watchers in apiserver sometimes is just to slow. In particular, I some log in my local branch and what I'm observing is that in etcd_watcher, we are: accumulating objects in incoming channel but also accumulating objects in outgoing channel, and the accumulation there is usually higher [I will send a PR to put those logs into master - they seem to be pretty useful for debugging such issues.] So my current hypothesis is that dispatching watch events to watchers is what is too slow. We will continue debugging.
The logs that I seem to confirm my hypothesis - outgoing channel is generally more full then the incoming channel in etcd_watcher: vs I'm working on the PR that should at least improve the situation.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.

https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Please apply the label to this issue if it does not need to be fixed before we launch 1.4. Otherwise please advise on how to proceed with respect to 1.4.
This was a regression - I fixed it by reverting an offending PR: This seems to be fixed now.
I have 33 pods in my container (1 is substantive, the other 32 just run on log files). I get this all the time now. I'm running 1.5.4.
- to be honest, I don't undertsand what your wrote. what is "container" in "33 pods in my container"? Also, if you believe there is a bug somewhere, please open a new issue instead of adding comment to more than half-year-old one.
Change:
# Make sure docker is installed gcutil ssh ${MINION_NAMES[$i]} which docker > /dev/null if [ "$?" != "0" ]; then <del> echo "Docker failed to install on ${MINION_NAMES[$i]}. Your cluster is unlikely to work correctly." echo "Please run ./cluster/kube-down.sh and re-create the cluster. (sorry!)" </del> <ins> echo "Docker failed to install on ${MINION_NAMES[$i]}. Your cluster is unlikely to work correctly." 1>&2 echo "Please run ./cluster/kube-down.sh and re-create the cluster. (sorry!)" 1>&2 </ins> exit 1 fi done

Discussion:
I'm following the documentation on this doc: Everything works until this command: I get this error consistently from different VMs (a Debian and a CoreOS). Maybe I have to edit /etc/hosts to add the "external-ip" with the public IP of some server? Docs don't seem clear. Thanks, Riccardo
Its failing to look up your master correctly. You can try setting KUBERNETES_MASTER=http://<your IP hearBrendan On Sep 21, 2014 5:45 AM, "Riccardo Carlesso" wrote:
Change:
} else { e2epod.ImagePrePullList.Insert(gpuDevicePluginImage) } <del> if samplePluginImage, err := getContainerImageFromE2ETestDaemonset(SampleDevicePluginDSYAML); err != nil { </del> <ins> if samplePluginImage, err := getSampleDevicePluginImage(); err != nil { </ins> klog.Errorln(err) } else { e2epod.ImagePrePullList.Insert(samplePluginImage) } <del> if samplePluginImageCtrlReg, err := getContainerImageFromE2ETestDaemonset(SampleDevicePluginControlRegistrationDSYAML); err != nil { klog.Errorln(err) } else { e2epod.ImagePrePullList.Insert(samplePluginImageCtrlReg) } </del> } func getNodeProblemDetectorImage() string {

Discussion:
Failing: ` Failing since . Last passing: First failing:
The diff () shows that went in which looks related
/sig node
/kind regression /kind bug /triage accepted
Change:
} } <del> func TestWaitingForGatesCondition(t *testing.T) { </del> <ins> func TestSchedulingGatedCondition(t *testing.T) { </ins> tests := []struct { name           string pod            *api.Pod

Discussion:
<img width="844" alt="image" src="" <img width="942" alt="image" src="" Here are some incorrect comments and function name about SchedulingGated Comments and function names need to be changed to SchedulingGated nothing 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
/assign
/sig scheduling
/remove-kind bug /kind cleanup
Change:
updateSessionAffinity := func(svc *v1.Service) { svc.Spec.SessionAffinity = v1.ServiceAffinityClientIP } <del> framework.UpdateService(f.ClientSet, config.NodePortService.Namespace, config.NodePortService.Name, updateSessionAffinity) firstEndpoints, err := config.GetEndpointsFromTestContainer("http", config.ClusterIP, framework.ClusterHttpPort, config.MaxTries, 0) </del> <ins> _, err := framework.UpdateService(f.ClientSet, config.NodePortService.Namespace, config.NodePortService.Name, updateSessionAffinity) </ins> if err != nil { <del> framework.Failf("Unable to get endpoints from test containers: %v", err) </del> <ins> framework.Failf("Failed to update service session affinity, error: %v", err) </ins> } <ins> // Fetch first endpoints when visiting service firstEndpoints, err := config.GetEndpointsFromTestContainer("http", config.ClusterIP, framework.ClusterHttpPort, config.MaxTries) if err != nil { framework.Failf("Unable to get endpoints from test container: %v", err) } // Check if first endpoints are equal to endpoints which are fetched later </ins> for i := 0; i < framework.SessionAffinityChecks; i++ { <del> eps, err := config.GetEndpointsFromTestContainer("http", config.ClusterIP, framework.ClusterHttpPort, config.MaxTries, 0) </del> <ins> eps, err := config.GetEndpointsFromTestContainer("http", config.ClusterIP, framework.ClusterHttpPort, config.MaxTries) </ins> if err != nil { <del> framework.Failf("Unable to get endpoints from test containers: %v", err) </del> <ins> framework.Failf("Unable to get endpoints from test container: %v", err) </ins> } if !eps.Equal(firstEndpoints) { framework.Failf("Expect endpoints: %v, got: %v", firstEndpoints, eps)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /priority failing-test /sig network What happened: From https://k8s-, seems to be broken right after they were by Example error message: and Anything else we need to know?: Is it as expected?
Oct 11 16:37:49.106: test session affinity, cost time: 1m31.742990485s This is a mistake. Sorry for my debug lines sneak in. I was just wondering why this test case doesn't run in upstream CI, so I this debug line. Now, I see because this test case only runs in . Oct 11 16:39:42.406: Expect endpoints: map[], got: map[netserver-1:{}] This check failed unexpectedly, let me try to find out why. I am working on it and will let you know soon when I have some updates.
Thanks. These two tests don't run on pull jobs as they are marked as , though https://k8s-, https://k8s- (and other CIs that include ) would have them running.
Do you mean when I raise a PR, these test cases will not be triggered? My question is how can I make sure my follow-up PR can fix this bug? Where can I access the log message when I raise a new PR?
Can I see the updated test results via directly visiting https://k8s-, https://k8s-
Yep, that is the current behavior. A hacky way to make it run on PR --- add a temporary commit to remove the word from test name so some pull jobs ( I think?) will run it. And you could view logs by clicking the button.
Nope, this CI only includes changes that are merged. It is basically a cronjob that runs tests against head.
Change:
}, errorType: "FieldValueRequired", }, <ins> "Address is link-local": { endpoints: api.Endpoints{ ObjectMeta: api.ObjectMeta{Name: "mysvc", Namespace: "namespace"}, Subsets: []api.EndpointSubset{ { Addresses: []api.EndpointAddress{{IP: "169.254.169.254"}}, Ports:     []api.EndpointPort{{Name: "p", Port: 93, Protocol: "TCP"}}, }, }, }, errorType:   "FieldValueInvalid", errorDetail: "link-local", }, </ins> } for k, v := range errorCases { <del> if errs := ValidateEndpoints(&v.endpoints); len(errs) == 0 || errs[0].(*errors.ValidationError).Type != v.errorType || errs[0].(*errors.ValidationError).Detail != v.errorDetail { </del> <ins> if errs := ValidateEndpoints(&v.endpoints); len(errs) == 0 || errs[0].(*errors.ValidationError).Type != v.errorType || !strings.Contains(errs[0].(*errors.ValidationError).Detail, v.errorDetail) { </ins> t.Errorf("Expected error type %s with detail %s for %s, got %v", v.errorType, v.errorDetail, k, errs) } }

Discussion:
Reported by It's possible to turn the master into a proxy to localhost or the GCE metadata server by adding a new endpoint that points to the service. To reproduce, add a new endpoint by posting to http://apiserver/api/v1beta3/endpoints with a description like: If you then go to http://apiserver/api/v1beta3/proxy/namespaces/default/services/myendpoint/ you can interact with the master's metadata server. We can't validate that Endpoints are within the cluster CIDR because we deliberately allow importing of external addresses -- that was the original purpose of allowing users to post Endpoints. I wouldn't disallow link-local and localhost addresses in Endpoints, either, since that might be useful in the future. I'd prefer to just disallow proxying to such addresses. Obviously we'd need to resolve DNS names before checking. See also cc
I think it would be simpler to disallow 169.254.0.0/16 as endpoints, document why and move on. The alternatives are more complicated and difficult to internalize and debug. , Robert Bailey wrote:
The user would either get an error when trying to post the Endpoints, or when trying to access the proxy. The latter is unlikely, IMO, except in malicious circumstances. The former would prevent using services to do something like publish a local metadata service (say, similar to the ) on a link-local address. But I'm ok with that approach for now, since it seems easy to change later.
Yeah, we can open it up as real requirements emerge, was my feeling. , Brian Grant wrote:
I agree w/ fix. Also we should block any similar range that AWS uses, etc.
Or resolve "metadata" and block just that.
Change:
} var printer kubecfg.ResourcePrinter <del> if *json { </del> <ins> switch { case *json: </ins> printer = &kubecfg.IdentityPrinter{} <del> } else if *yaml { </del> <ins> case *yaml: </ins> printer = &kubecfg.YAMLPrinter{} <del> } else { </del> <ins> case len(*templateFile) > 0 || len(*templateStr) > 0: var data []byte if len(*templateFile) > 0 { var err error data, err = ioutil.ReadFile(*templateFile) if err != nil { glog.Fatalf("Error reading template %s, %vn", *templateFile, err) return false } } else { data = []byte(*templateStr) } tmpl, err := template.New("output").Parse(string(data)) if err != nil { glog.Fatalf("Error parsing template %s, %vn", string(data), err) return false } printer = &kubecfg.TemplatePrinter{ Template: tmpl, } default: </ins> printer = &kubecfg.HumanReadablePrinter{} }

Discussion:
To remove dependence on jq and generally make scripting much easier, we should make another output flag which takes a formatter. We can use go's template package, which is very flexible.
Change:
.:53 { errors health <ins> ready </ins> kubernetes {{ pillar['dns_domain'] }} in-addr.arpa ip6.arpa { pods insecure <del> upstream </del> fallthrough in-addr.arpa ip6.arpa ttl 30 }

Discussion:
Which jobs are failing: Multiple jobs on . Which test(s) are failing: on the following jobs: Since when has it been failing: Since 5/17. Testgrid links: See above. Reason for failure: All the failures mentioned above seem to have to have the same root cause, namely failure while waiting for CoreDNS to be ready. Example: /sig testing /priority critical-urgent /kind failing test /milestone v1.15 /cc
Some of this (possible all of it) is due to , which is dependent on being merged.
/sig cluster-lifecycle
Not the gce jobs thoght. Only the kinder job. So the gce jobs are failing with a problem outside of kubeadm/kinder but possibly still related to the corefile plugin change
/assign (At kubecon this week)
The gce failures appear to show the same behavior, but with kube-up instead of kubeadm. I.e. it appears that kube-up may also be retaining old configs when upgrading/downgrading. If thats true, then we may need to integrate the migration tools into kube-up as well.
I have opened which aims to fix all the failing tests except , which will be fixed via
Great job so far and Would it be possible to ask for the open PRs to be merged and/or a solution found soon? We have these tests failing for quite some time and code freeze coming up in the next days. Thank you in advance for your efforts!
thanks for the heads up. let me know if you don't have the time for the refactor that i requested and i can try to take over there. the alternative is to rollback the coredns version which i assume is not ideal, due to a variety of fixes in the new version.
is there any more work planned for this issue? I see that some of the kinder jobs are still failing after merged:
merging and will resolve and close this issue.
Thank you for the update !
updates: kinder tests were fixed via
/unassign i was here for: it's a bit flaky (which is due to the tooling), but green.
Since and we're moved to 1.16, and we're waiting for to merge, can we move this issue to 1.16?
? is that the right PR?

Good catch, I meant
The GCE test failures were fixed by and /close
Closing this issue. <detailsIn response to : The GCE test failures were fixed by and /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:
f.eventRecorder.Eventf(p, nil, v1.EventTypeWarning, podWaitingReason, "", "") }() <del> return framework.NewStatus(framework.Wait), 100 * time.Second </del> <ins> return framework.NewStatus(framework.Wait), permitTimeout </ins> } var _ framework.PermitPlugin = &fakePermitPlugin{}

Discussion:
/kind failing-test /kind flake First seen in an unrelated PR, but also occurs in periodic jobs. /sig scheduling
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
/assign This feature is reverted once, and I fixed the flake, I'm cherry-pick that back again.
Change:
return nil } <del> if lbaas.opts.FloatingNetworkId != "" && loadbalancer != nil { </del> <ins> if loadbalancer != nil && loadbalancer.VipPortID != "" { </ins> portID := loadbalancer.VipPortID floatingIP, err := getFloatingIPByPortID(lbaas.network, portID) if err != nil && err != ErrNotFound {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: After deleting loadbalancer service, openstack cloud provider don't delete floatingip. What you expected to happen: After deleting loadbalancer service, openstack cloud provider delete floatingip. Anything else we need to know?: If ServiceAnnotationLoadBalancerFloatingNetworkId is specified to 'x.x.x.x' and the 'floating-network-id' is empty, openstack cloud provider don't delete floatingip. Environment: Kubernetes version (use ):latest Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig openstack
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
Change:
// Close stopCh to force checking if informers are synced now. close(stopCh) <del> var informersByStarted map[bool][]string for informerType, started := range i.sharedInformerFactory.WaitForCacheSync(stopCh) { </del> <ins> informersByStarted := make(map[bool][]string) for informerType, started := range i.cacheSyncWaiter.WaitForCacheSync(stopCh) { </ins> informersByStarted[started] = append(informersByStarted[started], informerType.String()) }

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 extension API server panics with: Apparently introduces this panic with . What you expected to happen: to do not panic. How to reproduce it (as minimally and precisely as possible): extension API server with - for example the endpoint that the apiserver panics with 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 regression
/sig api-machinery
/assign
cc
Oops - sorry for that. It seems it is basically this comment: that I blindly applied without e2e retesting (the problem seem to be lack of tests, which is a bit surprising because bugs in my previous implementations were caught by tests). ^^ BTW - this has been cherrypicked to previous releases: 16: 17: 18: so it's actually even more critical...
I can file the automated cherry-pick PRs once the PR against the master branch is merged. :)
Reopening - since we need to cherrypick it still.
I now opened the cherry-picks: 16 - 17 - 18 -
Fix and picks are merged
Change:
}, } _, _, w, done := NewIndexerInformerWatcher(lw, &corev1.Secret{}) <ins> defer w.Stop() </ins> // Expect secret add select {

Discussion:
In , when timeout or other error occurs, is called. This will make current routine terminated and miss the , which will lead to some leak routines. For example, this routine will block at waiting for No leak make any of these errors happen No response <details</details<details</details<details</details<details</details<details</details<details</details
sig Testing
I would like to take this up!
Actually, I have a fix in , but its fine if you have a better solution.
/sig api-machinery
/assign /triage accepted