jiebi/CodeConvo huggingface dataset:
Code change:
Currently scheduler latency are observed regardless of failure. For example, binding latency is like: This could be a potential confusion if latency spikes happen because of failure. We should better handle it like separating error case from normal
/cc
I completely agree - are you going to change this?
Yes. I will do it.

Related discussion:
text: var BindingSaturationReportInterval = 1 * time.Second var ( <del> E2eSchedulingLatency = prometheus.NewSummary( prometheus.SummaryOpts{ </del> <ins> E2eSchedulingLatency = prometheus.NewHistogram( prometheus.HistogramOpts{ </ins> Subsystem: schedulerSubsystem, Name:      "e2e_scheduling_latency_microseconds", Help:      "E2e scheduling latency (scheduling algorithm + binding)", <del> MaxAge:    time.Hour, </del> <ins> Buckets:   prometheus.ExponentialBuckets(1000, 2, 15), </ins> }, ) <del> SchedulingAlgorithmLatency = prometheus.NewSummary( prometheus.SummaryOpts{ </del> <ins> SchedulingAlgorithmLatency = prometheus.NewHistogram( prometheus.HistogramOpts{ </ins> Subsystem: schedulerSubsystem, Name:      "scheduling_algorithm_latency_microseconds", Help:      "Scheduling algorithm latency", <del> MaxAge:    time.Hour, </del> <ins> Buckets:   prometheus.ExponentialBuckets(1000, 2, 15), </ins> }, ) <del> BindingLatency = prometheus.NewSummary( prometheus.SummaryOpts{ </del> <ins> BindingLatency = prometheus.NewHistogram( prometheus.HistogramOpts{ </ins> Subsystem: schedulerSubsystem, Name:      "binding_latency_microseconds", Help:      "Binding latency", <del> MaxAge:    time.Hour, </del> <ins> Buckets:   prometheus.ExponentialBuckets(1000, 2, 15), </ins> }, ) BindingRateLimiterSaturation = prometheus.NewGauge(
Code change:
Currently scheduler latency are observed regardless of failure. For example, binding latency is like: This could be a potential confusion if latency spikes happen because of failure. We should better handle it like separating error case from normal
/cc
I completely agree - are you going to change this?
Yes. I will do it.

Related discussion:
text: glog.V(3).Infof("Attempting to schedule: %+v", pod) start := time.Now() <del> defer func() { metrics.E2eSchedulingLatency.Observe(metrics.SinceInMicroseconds(start)) }() </del> dest, err := s.config.Algorithm.Schedule(pod, s.config.NodeLister) <del> metrics.SchedulingAlgorithmLatency.Observe(metrics.SinceInMicroseconds(start)) </del> if err != nil { glog.V(1).Infof("Failed to schedule: %+v", pod) s.config.Recorder.Eventf(pod, api.EventTypeWarning, "FailedScheduling", "%v", err) s.config.Error(pod, err) return } <ins> metrics.SchedulingAlgorithmLatency.Observe(metrics.SinceInMicroseconds(start)) </ins> b := &api.Binding{ ObjectMeta: api.ObjectMeta{Namespace: pod.Namespace, Name: pod.Name}, Target: api.ObjectReference{
Code change:
Currently scheduler latency are observed regardless of failure. For example, binding latency is like: This could be a potential confusion if latency spikes happen because of failure. We should better handle it like separating error case from normal
/cc
I completely agree - are you going to change this?
Yes. I will do it.

Related discussion:
text: s.config.Modeler.LockedAction(func() { bindingStart := time.Now() err := s.config.Binder.Bind(b) <del> metrics.BindingLatency.Observe(metrics.SinceInMicroseconds(bindingStart)) </del> if err != nil { glog.V(1).Infof("Failed to bind pod: %+v", err) s.config.Recorder.Eventf(pod, api.EventTypeNormal, "FailedScheduling", "Binding rejected: %v", err) s.config.Error(pod, err) return } <ins> metrics.BindingLatency.Observe(metrics.SinceInMicroseconds(bindingStart)) </ins> s.config.Recorder.Eventf(pod, api.EventTypeNormal, "Scheduled", "Successfully assigned %v to %v", pod.Name, dest) // tell the model to assume that this binding took effect. assumed := *pod assumed.Spec.NodeName = dest s.config.Modeler.AssumePod(&assumed) }) <ins> metrics.E2eSchedulingLatency.Observe(metrics.SinceInMicroseconds(start)) </ins> }
Code change:
I noticed this flake by looking at the submit queue. The test is simple, but when it fails, we have no good way to debug it. Below is the test in question. When the test fails, we should print the lines we got in each case.

Related discussion:
text: By("restricting to a time range") time.Sleep(1500 * time.Millisecond) // ensure that startup logs on the node are seen as older than 1s <del> out = runKubectlOrDie("log", pod.Name, containerName, nsFlag, "--since=1s") recent := len(strings.Split(out, "n")) out = runKubectlOrDie("log", pod.Name, containerName, nsFlag, "--since=24h") older := len(strings.Split(out, "n")) Expect(recent).To(BeNumerically("<", older)) </del> <ins> recent_out := runKubectlOrDie("log", pod.Name, containerName, nsFlag, "--since=1s") recent := len(strings.Split(recent_out, "n")) older_out := runKubectlOrDie("log", pod.Name, containerName, nsFlag, "--since=24h") older := len(strings.Split(older_out, "n")) Expect(recent).To(BeNumerically("<", older), "expected recent(%v) to be less than older(%v)nrecent lines:n%vnolder lines:n%vn", recent, older, recent_out, older_out) </ins> }) }) })
Code change:
hack/build-cross sets it without looking at the current value. And the value has to be an array, which is a bit awkward to use.
This could be improved indeed. Maybe something like and Haven't tested it though... But why would one want to change the value?
I just wanted to build one, so I did the "obvious" thing: hack/dev-build-and-` It failed for multiple reasons :) , Lucas Käldström wrote:
This issue has been a major downer for me. It's much harder right now than it ought to be to articulate the few platforms for which you'd like to build each of server binaries, client binaries, test binaries, etc. Every time I've tried to do this "the right way," I've spent hours looking at scripts and feeling frustrated that build options aren't documented better. Every time, I end up cutting my losses and resorting to temporary build script hacks instead, just to get the job done.
Doesn't fix this issue exactly, but I've found that you can easily build only if you set .
Taking a look at this today, I also thought that setting seems to be the most reasonable.
/sig release

Related discussion:
text: readonly KUBE_NODE_BINARIES=("${KUBE_NODE_TARGETS[@]##*/}") readonly KUBE_NODE_BINARIES_WIN=("${KUBE_NODE_BINARIES[@]/%/.exe}") <del> if [[ "${KUBE_FASTBUILD:-}" == "true" ]]; then </del> <ins> if [[ -n "${KUBE_BUILD_PLATFORMS:-}" ]]; then readonly KUBE_SERVER_PLATFORMS=(${KUBE_BUILD_PLATFORMS}) readonly KUBE_NODE_PLATFORMS=(${KUBE_BUILD_PLATFORMS}) readonly KUBE_TEST_PLATFORMS=(${KUBE_BUILD_PLATFORMS}) readonly KUBE_CLIENT_PLATFORMS=(${KUBE_BUILD_PLATFORMS}) elif [[ "${KUBE_FASTBUILD:-}" == "true" ]]; then </ins> readonly KUBE_SERVER_PLATFORMS=(linux/amd64) readonly KUBE_NODE_PLATFORMS=(linux/amd64) if [[ "${KUBE_BUILDER_OS:-}" == "darwin"* ]]; then
Code change:
The delete command for a replicaset hangs forever. This then manifests as phantom RSs when I delete and recreate a namespace.
- delete is the gift that keeps on giving
cc
Had you already deleted the corresponding Deployment?
I am still seeing this problem. Deployments and replica sets are sticking.
From what I can tell, calling DELETE_COLLECTION on Deployments is returning: And since the controller assumes not found errors are equivalent to already deleted, it thinks the content is deleted. When I manually inspect, I still see the deployment and replica set laying around... //cc
holding on this while i debug some more...
This was a false alarm, apologies.

Related discussion:
text: pendingActionSet.Insert( strings.Join([]string{"delete-collection", "daemonsets", ""}, "-"), strings.Join([]string{"delete-collection", "deployments", ""}, "-"), <ins> strings.Join([]string{"delete-collection", "replicasets", ""}, "-"), </ins> strings.Join([]string{"delete-collection", "jobs", ""}, "-"), strings.Join([]string{"delete-collection", "horizontalpodautoscalers", ""}, "-"), strings.Join([]string{"delete-collection", "ingresses", ""}, "-"),
Code change:
The delete command for a replicaset hangs forever. This then manifests as phantom RSs when I delete and recreate a namespace.
- delete is the gift that keeps on giving
cc
Had you already deleted the corresponding Deployment?
I am still seeing this problem. Deployments and replica sets are sticking.
From what I can tell, calling DELETE_COLLECTION on Deployments is returning: And since the controller assumes not found errors are equivalent to already deleted, it thinks the content is deleted. When I manually inspect, I still see the deployment and replica set laying around... //cc
holding on this while i debug some more...
This was a false alarm, apologies.

Related discussion:
text: mockClient := fake.NewSimpleClientset(testInput.testNamespace) if containsVersion(versions, "extensions/v1beta1") { resources := []unversioned.APIResource{} <del> for _, resource := range []string{"daemonsets", "deployments", "jobs", "horizontalpodautoscalers", "ingresses"} { </del> <ins> for _, resource := range []string{"daemonsets", "deployments", "replicasets", "jobs", "horizontalpodautoscalers", "ingresses"} { </ins> resources = append(resources, unversioned.APIResource{Name: resource}) } mockClient.Resources = map[string]*unversioned.APIResourceList{
Code change:
The delete command for a replicaset hangs forever. This then manifests as phantom RSs when I delete and recreate a namespace.
- delete is the gift that keeps on giving
cc
Had you already deleted the corresponding Deployment?
I am still seeing this problem. Deployments and replica sets are sticking.
From what I can tell, calling DELETE_COLLECTION on Deployments is returning: And since the controller assumes not found errors are equivalent to already deleted, it thinks the content is deleted. When I manually inspect, I still see the deployment and replica set laying around... //cc
holding on this while i debug some more...
This was a false alarm, apologies.

Related discussion:
text: return estimate, err } } <ins> if containsResource(resources, "replicasets") { err = deleteReplicaSets(kubeClient.Extensions(), namespace) if err != nil { return estimate, err } } </ins> } return estimate, nil }
Code change:
The delete command for a replicaset hangs forever. This then manifests as phantom RSs when I delete and recreate a namespace.
- delete is the gift that keeps on giving
cc
Had you already deleted the corresponding Deployment?
I am still seeing this problem. Deployments and replica sets are sticking.
From what I can tell, calling DELETE_COLLECTION on Deployments is returning: And since the controller assumes not found errors are equivalent to already deleted, it thinks the content is deleted. When I manually inspect, I still see the deployment and replica set laying around... //cc
holding on this while i debug some more...
This was a false alarm, apologies.

Related discussion:
text: return expClient.Deployments(ns).DeleteCollection(nil, api.ListOptions{}) } <ins> func deleteReplicaSets(expClient extensions_unversioned.ExtensionsInterface, ns string) error { return expClient.ReplicaSets(ns).DeleteCollection(nil, api.ListOptions{}) } </ins> func deleteIngress(expClient extensions_unversioned.ExtensionsInterface, ns string) error { return expClient.Ingresses(ns).DeleteCollection(nil, api.ListOptions{}) }
Code change:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.

Related discussion:
text: func TestClient(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> ns := api.NamespaceDefault framework.DeleteAllEtcdKeys()
Code change:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.

Related discussion:
text: func TestSingleWatch(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> ns := "blargh" deleteAllEtcdKeys()
Code change:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.

Related discussion:
text: framework.DeleteAllEtcdKeys() defer framework.DeleteAllEtcdKeys() _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> ns := api.NamespaceDefault client := client.NewOrDie(&client.Config{Host: s.URL, ContentConfig: client.ContentConfig{GroupVersion: testapi.Default.GroupVersion()}})
Code change:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.

Related discussion:
text: func TestExperimentalPrefix(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> resp, err := http.Get(s.URL + "/apis/extensions/") if err != nil {
Code change:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.

Related discussion:
text: func TestWatchSucceedsWithoutArgs(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> resp, err := http.Get(s.URL + "/api/v1/namespaces?watch=1") if err != nil {
Code change:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.

Related discussion:
text: func TestAccept(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> resp, err := http.Get(s.URL + "/api/") if err != nil {
Code change:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.

Related discussion:
text: func TestMasterProcessMetrics(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> metrics, err := scrapeMetrics(s) if err != nil {
Code change:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.

Related discussion:
text: func TestApiserverMetrics(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> // Make a request to the apiserver to ensure there's at least one data point // for the metrics we're expecting -- otherwise, they won't be exported.
Code change:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.

Related discussion:
text: func TestPersistentVolumeRecycler(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> deleteAllEtcdKeys() // Use higher QPS and Burst, there is a test for race condition below, which
Code change:
I'm following step by step tutorial on how to create resource quotas per namespace () looks like this: { "apiVersion": "v1", "kind": "ResourceQuota", "metadata": { "name": "quota", }, "spec": { "hard": { "memory": "1Gi", "cpu": "20", "pods": "10", "services": "5", "replicationcontrollers":"20", "resourcequotas":"1", }, } when i'm about to create quota it fails with: kubectl create -f --namespace=prod invalid character '}' looking for beginning of object key string Namespace "prod" exists: kubectl get namespace NAME LABELS STATUS AGE default &lt;noneActive 26d dev name=development Active 8d kube-system &lt;noneActive 26d prod name=production Active 8d kubectl version Client Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.2", GitCommit:"", GitTreeState:"clean"} Server Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.2", GitCommit:"", GitTreeState:"clean"}
Those trailing commas are wrong. should look like: I'll submit a docs patch
sweet. ta. That seem to do the trick: kubectl create -f --namespace=prod resourcequota "quota" created
I'm going to reopen until the PR which fixes this merges, when it should autoclose...
I'm following this tutorial on installing percona with kubectl, and I'm getting a similar error: When I run: kubectl create -f pmm-server- I get: error: json: line 1: invalid character ‘Â’ looking for beginning of object key string

Related discussion:
text: "apiVersion": "v1", "kind": "ResourceQuota", "metadata": { <del> "name": "quota", </del> <ins> "name": "quota" </ins> }, "spec": { "hard": {
Code change:
I'm following step by step tutorial on how to create resource quotas per namespace () looks like this: { "apiVersion": "v1", "kind": "ResourceQuota", "metadata": { "name": "quota", }, "spec": { "hard": { "memory": "1Gi", "cpu": "20", "pods": "10", "services": "5", "replicationcontrollers":"20", "resourcequotas":"1", }, } when i'm about to create quota it fails with: kubectl create -f --namespace=prod invalid character '}' looking for beginning of object key string Namespace "prod" exists: kubectl get namespace NAME LABELS STATUS AGE default &lt;noneActive 26d dev name=development Active 8d kube-system &lt;noneActive 26d prod name=production Active 8d kubectl version Client Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.2", GitCommit:"", GitTreeState:"clean"} Server Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.2", GitCommit:"", GitTreeState:"clean"}
Those trailing commas are wrong. should look like: I'll submit a docs patch
sweet. ta. That seem to do the trick: kubectl create -f --namespace=prod resourcequota "quota" created
I'm going to reopen until the PR which fixes this merges, when it should autoclose...
I'm following this tutorial on installing percona with kubectl, and I'm getting a similar error: When I run: kubectl create -f pmm-server- I get: error: json: line 1: invalid character ‘Â’ looking for beginning of object key string

Related discussion:
text: "pods": "10", "services": "5", "replicationcontrollers":"20", <del> "resourcequotas":"1", }, </del> <ins> "resourcequotas":"1" } </ins> } } EOF
Code change:
The says this about the new GUI: It does not what? Seems important!
Hmm... That's interesting. Will fix.

Related discussion:
text: trigger scaling up and down the number of pods in your application. * <strong>New GUI</strong> (dashboard) allows you to get started quickly and enables the same functionality found in the CLI as a more approachable and discoverable way of <del> interacting with the system. Note: the GUI is eanbled by default for new cluster creation, however, it does not </del> <ins> interacting with the system. Note: the GUI is enabled by default in 1.2 clusters. </ins> <del> <img src="docs/images/newgui.png" width="" alt="XXX image" title="XXX image tooltip"> </del> <ins> <img src="docs/images/newgui.png" width="" alt="Dashboard UI screenshot showing cards that represent applications that run inside a cluster" title="Dashboard UI apps screen"> </ins> ## Other notable improvements