jiebi/CodeConvo huggingface dataset:
Code change:
The code in doesn't work for me: does not pass on SIGTERM when the caller is in the same process group. Then the knocks out the process without giving it a chance to kill its child. The bit doesn't help: either the process has already been killed as above, or it gets killed now with SIGKILL; either way the process is still running. Oddly, it does work about one time in ten. I have no explanation for that. I am running from the command-line like this: , on 0-41-generic -Ubuntu SMP Fri Jun 24 11:28:43 UTC 2016 x8664 x8664 x86_64 GNU/Linux CC
The manual says "This is the signal that the calling process will get when its parent dies."; it is applied to the process, so that will get killed if the process dies. That isn't what we are looking for:

Related discussion:
text: cmd.Cmd.Stdout = outfile cmd.Cmd.Stderr = outfile <del> // Killing the sudo command should kill the server as well. </del> <ins> // Death of this test process should kill the server as well. </ins> attrs := &syscall.SysProcAttr{} // Hack to set linux-only field without build tags. deathSigField := reflect.ValueOf(attrs).Elem().FieldByName("Pdeathsig") if deathSigField.IsValid() { <del> deathSigField.Set(reflect.ValueOf(syscall.SIGKILL)) </del> <ins> deathSigField.Set(reflect.ValueOf(syscall.SIGTERM)) </ins> } else { cmdErrorChan <- fmt.Errorf("Failed to set Pdeathsig field (non-linux build)") return
Code change:
The code in doesn't work for me: does not pass on SIGTERM when the caller is in the same process group. Then the knocks out the process without giving it a chance to kill its child. The bit doesn't help: either the process has already been killed as above, or it gets killed now with SIGKILL; either way the process is still running. Oddly, it does work about one time in ten. I have no explanation for that. I am running from the command-line like this: , on 0-41-generic -Ubuntu SMP Fri Jun 24 11:28:43 UTC 2016 x8664 x8664 x86_64 GNU/Linux CC
The manual says "This is the signal that the calling process will get when its parent dies."; it is applied to the process, so that will get killed if the process dies. That isn't what we are looking for:

Related discussion:
text: const timeout = 10 * time.Second for _, signal := range []string{"-TERM", "-KILL"} { glog.V(2).Infof("Killing process %d (%s) with %s", pid, name, signal) <del> _, err := exec.Command("sudo", "kill", signal, strconv.Itoa(pid)).Output() </del> <ins> cmd := exec.Command("sudo", "kill", signal, strconv.Itoa(pid)) // Run the 'kill' command in a separate process group so sudo doesn't ignore it attrs := &syscall.SysProcAttr{} // Hack to set unix-only field without build tags. setpgidField := reflect.ValueOf(attrs).Elem().FieldByName("Setpgid") if setpgidField.IsValid() { setpgidField.Set(reflect.ValueOf(true)) } else { return fmt.Errorf("Failed to set Setpgid field (non-unix build)") } cmd.SysProcAttr = attrs _, err := cmd.Output() </ins> if err != nil { glog.Errorf("Error signaling process %d (%s) with %s: %v", pid, name, signal, err) continue
Code change:
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention...
This has been marked with the "needs attention" label and needs to be addressed for the 1.4 release. Could you please close if it's fixed update on your progress to fix it make a case for it not to block the release or find a new owner who can do one of the above soon. Once you or the new owner update this issue and are actively working on it, you can remove the "needs attention" label.
the following message looks suspicious, looks a DNS issue?
Actually more like a network connectivity issue
do you happen to have the Dockerfile for these images? We better push them into
I don't think this is a blocking issue. It looks a transient issue. Since the example is largely dependent on whether the image can be fetched and how long it takes to pull the image, it is very environment sensitive. I would recommend removing label. Longer term, we should move the images used in examples to gcr.
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
for the last flake, based on , image pull (mattf/zookeeper:latest) started at 42:40, finished at 48:31, about 5min51sec, well passed 5 min
storm-nimbus, storm-worker and zookeeper are from they're all automated builds from github (quick link: and )
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}

Related discussion:
text: workerControllerJson := mkpath("storm-worker-controller.json") nsFlag := fmt.Sprintf("--namespace=%v", ns) zookeeperPod := "zookeeper" <ins> nimbusPod := "nimbus" </ins> By("starting Zookeeper") framework.RunKubectlOrDie("create", "-f", zookeeperPodJson, nsFlag) framework.RunKubectlOrDie("create", "-f", zookeeperServiceJson, nsFlag) <del> err := framework.WaitForPodNameRunningInNamespace(c, zookeeperPod, ns) </del> <ins> err := f.WaitForPodRunningSlow(zookeeperPod) </ins> Expect(err).NotTo(HaveOccurred()) By("checking if zookeeper is up and running")
Code change:
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention...
This has been marked with the "needs attention" label and needs to be addressed for the 1.4 release. Could you please close if it's fixed update on your progress to fix it make a case for it not to block the release or find a new owner who can do one of the above soon. Once you or the new owner update this issue and are actively working on it, you can remove the "needs attention" label.
the following message looks suspicious, looks a DNS issue?
Actually more like a network connectivity issue
do you happen to have the Dockerfile for these images? We better push them into
I don't think this is a blocking issue. It looks a transient issue. Since the example is largely dependent on whether the image can be fetched and how long it takes to pull the image, it is very environment sensitive. I would recommend removing label. Longer term, we should move the images used in examples to gcr.
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
for the last flake, based on , image pull (mattf/zookeeper:latest) started at 42:40, finished at 48:31, about 5min51sec, well passed 5 min
storm-nimbus, storm-worker and zookeeper are from they're all automated builds from github (quick link: and )
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] [Feature:Example] [] Storm should create and stop Zookeeper, Nimbus and Storm worker servers {Kubernetes e2e suite}

Related discussion:
text: By("starting Nimbus") framework.RunKubectlOrDie("create", "-f", nimbusPodJson, nsFlag) framework.RunKubectlOrDie("create", "-f", nimbusServiceJson, nsFlag) <del> err = framework.WaitForPodNameRunningInNamespace(c, "nimbus", ns) </del> <ins> err = f.WaitForPodRunningSlow(nimbusPod) </ins> Expect(err).NotTo(HaveOccurred()) err = framework.WaitForEndpoint(c, ns, "nimbus")
Code change:
I think got confused between e.g. KUBEMASTEROSDISTRIBUTION and MASTEROS_DISTRIBUTION; it definitely doesn't match GCE. PR coming in once I've tested.
cc

Related discussion:
text: # OS options for minions KUBE_OS_DISTRIBUTION="${KUBE_OS_DISTRIBUTION:-jessie}" <del> KUBE_MASTER_OS_DISTRIBUTION="${KUBE_OS_DISTRIBUTION}" KUBE_NODE_OS_DISTRIBUTION="${KUBE_OS_DISTRIBUTION}" </del> <ins> MASTER_OS_DISTRIBUTION="${KUBE_OS_DISTRIBUTION}" NODE_OS_DISTRIBUTION="${KUBE_OS_DISTRIBUTION}" </ins> KUBE_NODE_IMAGE="${KUBE_NODE_IMAGE:-}" COREOS_CHANNEL="${COREOS_CHANNEL:-alpha}" CONTAINER_RUNTIME="${KUBE_CONTAINER_RUNTIME:-docker}"
Code change:
Description of problem Create a petset, when pod is evicted, the petset can't create a new pod on other node and make sure pod is running. Kubernetes version (use ): v1.4.0-alpha.2.1427+ How to reproduce it (as minimally and precisely as possible): kubele eviction-hard="memory.available<${value}" a peset and wait all pod is running node MemoryPressure=true all pod status What happened: is evicted and petset can't create new pod and make sure pod is running. What you expected to happen: create new pod on other node and make sure pod is running.
Also when node come back with sufficient memory, petset can't make pod running again.
FYI
cc
Was able to reproduce it. Pet set controller just loops with the following logs I0830 12:32:52. 9 ] Syncing PetSet default/cockroachdb with 3 pets I0830 12:32:52. 9 ] PetSet cockroachdb blocked from scaling on pet cockroachdb-0 I0830 12:32:52. 9 ] PetSet cockroachdb waiting on unhealthy pet cockroachdb-0 I0830 12:32:52. 9 ] PetSet cockroachdb waiting on unhealthy pet cockroachdb-1 I0830 12:32:52. 9 ] PetSet cockroachdb waiting on unhealthy pet cockroachdb-2
-- do you have the petset YAML that we can evaluate? What is the quality of service tier for the pods produced by the petset? Can you include the of an evicted petset pod so we can see the final resource requirements spec?
I am able to reproduce it with nginx pet set in e2e test. Here is yaml output of it Also it seems that i have working fix and almost finished debugging e2e test (patchset is linked above). Will be grateful for review.
Ah, this helps clear things up... the linked pr shows the problem in petset controller and not kubelet...
Does it make sense to set milestone 1.4 for this issue? I think the fix is ready for review

Related discussion:
text: if err := p.SyncPVCs(pet); err != nil { return err } <del> if exists { </del> <ins> // if pet failed - we need to remove old one because of consistent naming if exists && realPet.pod.Status.Phase == api.PodFailed { glog.V(4).Infof("Delete evicted pod %v", realPet.pod.Name) if err := p.petClient.Delete(realPet); err != nil { return err } } else if exists { </ins> if !p.isHealthy(realPet.pod) { glog.Infof("PetSet %v waiting on unhealthy pet %v", pet.parent.Name, realPet.pod.Name) }
Code change:
Description of problem Create a petset, when pod is evicted, the petset can't create a new pod on other node and make sure pod is running. Kubernetes version (use ): v1.4.0-alpha.2.1427+ How to reproduce it (as minimally and precisely as possible): kubele eviction-hard="memory.available<${value}" a peset and wait all pod is running node MemoryPressure=true all pod status What happened: is evicted and petset can't create new pod and make sure pod is running. What you expected to happen: create new pod on other node and make sure pod is running.
Also when node come back with sufficient memory, petset can't make pod running again.
FYI
cc
Was able to reproduce it. Pet set controller just loops with the following logs I0830 12:32:52. 9 ] Syncing PetSet default/cockroachdb with 3 pets I0830 12:32:52. 9 ] PetSet cockroachdb blocked from scaling on pet cockroachdb-0 I0830 12:32:52. 9 ] PetSet cockroachdb waiting on unhealthy pet cockroachdb-0 I0830 12:32:52. 9 ] PetSet cockroachdb waiting on unhealthy pet cockroachdb-1 I0830 12:32:52. 9 ] PetSet cockroachdb waiting on unhealthy pet cockroachdb-2
-- do you have the petset YAML that we can evaluate? What is the quality of service tier for the pods produced by the petset? Can you include the of an evicted petset pod so we can see the final resource requirements spec?
I am able to reproduce it with nginx pet set in e2e test. Here is yaml output of it Also it seems that i have working fix and almost finished debugging e2e test (patchset is linked above). Will be grateful for review.
Ah, this helps clear things up... the linked pr shows the problem in petset controller and not kubelet...
Does it make sense to set milestone 1.4 for this issue? I think the fix is ready for review

Related discussion:
text: "k8s.io/kubernetes/pkg/controller/petset" "k8s.io/kubernetes/pkg/labels" "k8s.io/kubernetes/pkg/runtime" <ins> "k8s.io/kubernetes/pkg/types" </ins> "k8s.io/kubernetes/pkg/util/sets" "k8s.io/kubernetes/pkg/util/wait" utilyaml "k8s.io/kubernetes/pkg/util/yaml" <ins> "k8s.io/kubernetes/pkg/watch" </ins> "k8s.io/kubernetes/test/e2e/framework" ) const ( petsetPoll = 10 * time.Second // Some pets install base packages via wget <del> petsetTimeout           = 10 * time.Minute </del> <ins> petsetTimeout = 10 * time.Minute // Timeout for pet pods to change state petPodTimeout           = 5 * time.Minute </ins> zookeeperManifestPath   = "test/e2e/testing-manifests/petset/zookeeper" mysqlGaleraManifestPath = "test/e2e/testing-manifests/petset/mysql-galera" redisManifestPath       = "test/e2e/testing-manifests/petset/redis"
Code change:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? Currently, the 4th parameter name of updateServiceListener in kube-proxy is addOrDelete, However, from the func caller, we just pass for AddServiceListener, and for DeleteServiceListener, So, I think the name addOrDelete is unreasonable. I prefer to change the parameter name addOrDelete to add so that avoid making people confused. In addition, there is a typo, We should change addition to deletion! Also, there is a sentence breaking, we should change from No Service Endpoints Not Found =No Service Endpoints are found Thanks!
Fixed!

Related discussion:
text: healthchecker.mutationRequestChannel <- req } <del> func updateServiceListener(serviceName types.NamespacedName, listenPort int, addOrDelete bool) bool { </del> <ins> func updateServiceListener(serviceName types.NamespacedName, listenPort int, add bool) bool { </ins> responseChannel := make(chan bool) req := &proxyListenerRequest{ serviceName:     serviceName, listenPort:      uint16(listenPort), <del> add:             addOrDelete, </del> <ins> add:             add, </ins> responseChannel: responseChannel, } healthchecker.listenerRequestChannel <- req
Code change:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? Currently, the 4th parameter name of updateServiceListener in kube-proxy is addOrDelete, However, from the func caller, we just pass for AddServiceListener, and for DeleteServiceListener, So, I think the name addOrDelete is unreasonable. I prefer to change the parameter name addOrDelete to add so that avoid making people confused. In addition, there is a typo, We should change addition to deletion! Also, there is a sentence breaking, we should change from No Service Endpoints Not Found =No Service Endpoints are found Thanks!
Fixed!

Related discussion:
text: return updateServiceListener(serviceName, listenPort, true) } <del> // DeleteServiceListener Request addition of a listener for a service's health check </del> <ins> // DeleteServiceListener Request deletion of a listener for a service's health check </ins> func DeleteServiceListener(serviceName types.NamespacedName, listenPort int) bool { return updateServiceListener(serviceName, listenPort, false) }
Code change:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? Currently, the 4th parameter name of updateServiceListener in kube-proxy is addOrDelete, However, from the func caller, we just pass for AddServiceListener, and for DeleteServiceListener, So, I think the name addOrDelete is unreasonable. I prefer to change the parameter name addOrDelete to add so that avoid making people confused. In addition, there is a typo, We should change addition to deletion! Also, there is a sentence breaking, we should change from No Service Endpoints Not Found =No Service Endpoints are found Thanks!
Fixed!

Related discussion:
text: s, ok := h.serviceEndpointsMap.Get(serviceName) if !ok { glog.V(4).Infof("Service %s not found or has no local endpoints", serviceName) <del> sendHealthCheckResponse(rw, http.StatusServiceUnavailable, "No Service Endpoints Not Found") </del> <ins> sendHealthCheckResponse(rw, http.StatusServiceUnavailable, "No Service Endpoints Found") </ins> return } numEndpoints := len(*s.(*serviceEndpointsList).endpoints)
Code change:
In practice this means that it doesn't get to update and thereby may refuse to admit pods which had been assigned to it by the scheduler. For example, if you update labels for that given node, and try to use affinity or on a pod, it won't get to run.
This looks like a sufficient fix for me, but I'm happy to add instead, if that'd help getting it accepted for 1.4.0: cc
cc
That commit makes sense to me.
Thanks, I'll open a PR.

Related discussion:
text: func run(s *options.KubeletServer, kubeDeps *kubelet.KubeletDeps) (err error) { // TODO: this should be replaced by a --standalone flag <del> standaloneMode := (len(s.APIServerList) == 0) </del> <ins> standaloneMode := (len(s.APIServerList) == 0 && !s.RequireKubeConfig) </ins> if s.ExitOnLockContention && s.LockFilePath == "" { return errors.New("cannot exit on lock file contention: no lock file specified")
Code change:
While following this to setup a kube-mesos integration env on my laptop, I found the default service account and default token are not created when start the cluster. As a result, I can not create a pod or deployment in this environment. Reproduce steps: the latest Mesos code, build and start 1 single master with 1 single agent. the latest Kubernetes code, use to build. the following commands to start apiserver, controller-manager and scheduler respectively: all the components are started, run command and see that there is no default token created for the default namespace. At this moment, run "kubectl create -f " will see the failure of creating a pod.
This introduced to node controller and now when we start a node controller, if is not nil, we will start this Informer controller as well. But the start of the will block main thread from starting other controllers later in the main thread. we can see that in the kube-mesos integration, we started some other controllers, including serviceaccount controller, after we started node controller. I will submit a patch later to run the in a go routine to solve the issue.

Related discussion:
text: go nc.podController.Run(wait.NeverStop) go nc.daemonSetController.Run(wait.NeverStop) if nc.internalPodInformer != nil { <del> nc.internalPodInformer.Run(wait.NeverStop) </del> <ins> go nc.internalPodInformer.Run(wait.NeverStop) </ins> } // Incorporate the results of node status pushed from kubelet to master.
Code change:
https://k8s- Failed: ThirdParty resources Simple Third Party creating/deleting thirdparty objects works [Conformance] {Kubernetes e2e suite}
cc
Seems like the namespace creation/deletion process is flaky. IIRC there have been some recent PRs touching this area, is that right?
We recently code to try to expose the real underlying error for why the ns deletion fails. This is hopefully now showing it.
The issue is with TPR not integrated properly with the namespace controller. Creation of a new type requires a restart of the controller-manager given current state of the code. The test must be marked flaky until the state of the art is improved (which is not happening in 1.4).

Related discussion:
text: Items []Foo `json:"items"` } <del> var _ = Describe("ThirdParty resources", func() { </del> <ins> // This test is marked flaky pending namespace controller observing dynamic creation of new third party types. var _ = Describe("ThirdParty resources [Flaky] [Disruptive]", func() { </ins> f := framework.NewDefaultFramework("thirdparty")
Code change:
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.

Related discussion:
text: c.forget(false) c.stop() } <ins> glog.V(2).Infof("cacheWatcher add function blocked processing for %v", time.Since(startTime)) </ins> } func (c *cacheWatcher) sendWatchCacheEvent(event watchCacheEvent) {