jiebi/CodeConvo huggingface dataset:
Change:
eventBroadcaster := record.NewBroadcaster() eventBroadcaster.StartLogging(glog.Infof) eventBroadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: v1core.New(kubeClient.Core().RESTClient()).Events("")}) <del> recorder := eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "attachdetach"}) </del> <ins> recorder := eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "attachdetach-controller"}) </ins> adc.desiredStateOfWorld = cache.NewDesiredStateOfWorld(&adc.volumePluginMgr) adc.actualStateOfWorld = cache.NewActualStateOfWorld(&adc.volumePluginMgr)

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 feature What happened: kubect create -f to create statefulset, and describe the statefulset, output the event likes <preEvents: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 statefulset Normal SuccessfulCreate create Claim www-web-0 Pod web-0 in StatefulSet web success 1m 1m 1 statefulset Normal SuccessfulCreate create Pod web-0 in StatefulSet web successful </preWhat you expected to happen: the From of event change to 'statefulset-controller' in output, let know the source of event more obvious, likes the event when create job and other resource(replicaset,replication). <preEvents: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 3m 3m 1 job-controller Normal SuccessfulCreate Created pod: pi-7gd2m </preHow to reproduce it (as minimally and precisely as possible): create a statefulset and describe it to see the event Anything else we need to know?: Environment: Kubernetes version (use ):kubernetes 1.7 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: 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
/assign
/area controller-manager
/sig node
Change:
RUN mkdir -p ${K8S_PATCHED_GOROOT}  && curl -sSL https://github.com/golang/go/archive/go${K8S_PATCHED_GOLANG_VERSION}.tar.gz | tar -xz -C ${K8S_PATCHED_GOROOT} --strip-components=1 <ins> # We need a patched go1.7.1 for linux/arm (https://github.com/kubernetes/kubernetes/issues/29904) # We need go1.7.1 for all darwin builds (https://github.com/kubernetes/kubernetes/issues/32999) </ins> COPY golang-patches/CL28857-go1.7.1-luxas.patch ${K8S_PATCHED_GOROOT}/ RUN cd ${K8S_PATCHED_GOROOT}  && patch -p1 < CL28857-go1.7.1-luxas.patch  && cd src  && GOROOT_FINAL=${K8S_PATCHED_GOROOT} GOROOT_BOOTSTRAP=/usr/local/go ./make.bash  <del> && for platform in linux/arm; do GOOS=${platform%/*} GOARCH=${platform##*/} GOROOT=${K8S_PATCHED_GOROOT} go install std; done </del> <ins> && for platform in linux/arm darwin/386 darwin/amd64; do GOOS=${platform%/*} GOARCH=${platform##*/} GOROOT=${K8S_PATCHED_GOROOT} go install std; done </ins>

Discussion:
See
CI has built and uploaded unofficial prerelease darwin binaries for 1.4 using go1.7.1: cc Official binaries will ship as soon as we cut 1.4.1.
We have official v1.4.1 binaries available now, too.
Hooray
Change:
}, }, { <ins> name: "pod with init containers", opts: &DebugOptions{ CopyTo:     "debugger", Image:      "busybox", PullPolicy: corev1.PullIfNotPresent, }, pod: &corev1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "target", }, Spec: corev1.PodSpec{ InitContainers: []corev1.Container{ { Name: "init-container-1", }, { Name: "init-container-2", }, }, Containers: []corev1.Container{ { Name: "debugger-1", }, }, }, }, expected: &corev1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "debugger", }, Spec: corev1.PodSpec{ InitContainers: []corev1.Container{ { Name: "init-container-1", }, { Name: "init-container-2", }, }, Containers: []corev1.Container{ { Name: "debugger-1", }, { Name:                     "debugger-2", Image:                    "busybox", ImagePullPolicy:          corev1.PullIfNotPresent, TerminationMessagePolicy: corev1.TerminationMessageReadFile, }, }, }, }, }, { name: "pod with ephemeral containers", opts: &DebugOptions{ CopyTo:     "debugger", Image:      "busybox", PullPolicy: corev1.PullIfNotPresent, }, pod: &corev1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "target", }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Name: "debugger-1", }, }, EphemeralContainers: []corev1.EphemeralContainer{ { EphemeralContainerCommon: corev1.EphemeralContainerCommon{ Name: "ephemeral-container-1", }, }, { EphemeralContainerCommon: corev1.EphemeralContainerCommon{ Name: "ephemeral-container-2", }, }, }, }, }, expected: &corev1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "debugger", }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Name: "debugger-1", }, { Name:                     "debugger-2", Image:                    "busybox", ImagePullPolicy:          corev1.PullIfNotPresent, TerminationMessagePolicy: corev1.TerminationMessageReadFile, }, }, }, }, }, { </ins> name: "shared process namespace", opts: &DebugOptions{ CopyTo:                "debugger",

Discussion:
What happened: When using to create a debug container for a pod that has multiple init containers or ephemeral containers, fails with . What you expected to happen: should create a debug container in pod successfully. How to reproduce it (as minimally and precisely as possible): The EphemeralContainers feature gate must be enabled by using flag in your cluster. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): NAME="CentOS Linux" VERSION="7 (Core)" Kernel (e.g. ): Linux node-1 3.10.0-957.el7.x8664 SMP Thu Nov 8 23:39:32 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others: /sig cli
I have investigated this issue and it looks like this issue happens in the following cases. When using without option When using with option In those cases, the containerNameToRef function is called and each for-loop in the function refers to the same despite the range is , or .
cc If this issue needs to be fixed, I would like to work on this.
/assign
Thanks for the report and for fixing it!
Change:
To run serialization tests just for the current version: ```sh <del> go test ./vendor/k8s.io/api -run //HEAD </del> <ins> go test k8s.io/api -run //HEAD </ins> ``` All three formats of a given group/version/kind are expected to decode successfully to identical objects,

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 --I tried rebasing an old open PR, and got merge conflicts on api testdata. I read and tried the command listed there for regenerating the test data. It failed as follows. I expected successful regeneration of the api test data. Checkout and issue the command exhibited above. Kubernetes version (use ): is at commit right nowCloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc
ah, latest go versions changed the invocation to
fixed in
/triage accepted
Change:
go func() { doneChan <- pf.ForwardPorts() }() <del> select { case <-pf.Ready: case <-time.After(500 * time.Millisecond): t.Fatalf("%d: timed out waiting for listeners", i) } </del> <ins> <-pf.Ready </ins> conn := testCase.Upgrader.conn

Discussion:
this is you
Hmm, I had upped waiting from 100ms to 500ms and that seemed to fix it. Do you have any better ideas?
Don't wait? :)
If the only reason you would timeout would be the code is broken, that's why the test runs have -timeout set.
Then the test fails immediately. It's waiting for the net.Listen calls to finish so it can connect to the specified local ports.
*finish enough so that socket connections work
So I can remove the timeout gating in my tests?
Yes ----- Original Message -----
Just failed again: https://travis-
Seems to be failing frequently now.
If this is test is failing again, my gut says it's not the same root cause. The original failure was a timeout issue. This new one is connection reset by peer. I've got the test running in a loop waiting for a failure but haven't seen one yet. is this still failing frequently?
No. It had failed twice in ~10 builds when I reopened this issue, but hasn't failed since. Reclosing. Will file a new issue if it recurs.
Change:
} } }() <del> if e.services == nil { glog.Errorf("can't stop e2e services, because `services` is nil") </del> <ins> if e.services != nil { if err := e.services.kill(); err != nil { glog.Errorf("Failed to stop services: %v", err) } } if e.kubelet != nil { if err := e.kubelet.kill(); err != nil { glog.Errorf("Failed to stop kubelet: %v", err) } </ins> } <del> return e.services.kill() </del> } // RunE2EServices actually start the e2e services. This function is used to

Discussion:
In node e2e, we have the option to keep the services running after test for further debug. However, we set to for the services, which means that once the parent exits, they will receive and exit with the parent if they don't trap the signal. With this, option will never work. If we still need this feature, we should not set if is false. /cc
We still need this feature. It helps with debugging test failures by keeping all the daemons running upon failure. , Lantao Liu wrote:
Change:
} } <ins> func TestRejectWaitingPod(t *testing.T) { pod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "pod", UID:  types.UID("pod"), }, } testPermitPlugin := &TestPermitPlugin{} r := make(Registry) r.Register(permitPlugin, func(_ *runtime.Unknown, fh FrameworkHandle) (Plugin, error) { return testPermitPlugin, nil }) plugins := &config.Plugins{ Permit: &config.PluginSet{Enabled: []config.Plugin{{Name: permitPlugin, Weight: 1}}}, } f, err := NewFramework(r, plugins, emptyArgs) if err != nil { t.Fatalf("Failed to create framework for testing: %v", err) } go func() { for { waitingPod := f.GetWaitingPod(pod.UID) if waitingPod != nil { break } } f.RejectWaitingPod(pod.UID) }() permitStatus := f.RunPermitPlugins(context.Background(), nil, pod, "") if permitStatus.message != "pod "pod" rejected while waiting at permit: removed" { t.Fatalf("RejectWaitingPod failed, permitStatus: %v", permitStatus) } } </ins> func buildScoreConfigDefaultWeights(ps ...string) *config.Plugins { return buildScoreConfigWithWeights(defaultWeights, ps...) }

Discussion:
What would you like to be : When the pod is scheduled to the phase and I delete the pod, the pod still remains in the until the plugin allow/reject/timeout(Especially when waiting for a long time). Why is this needed: We need to take the initiative to delete the data in the and terminate the process in waiting state of plugin to ensure data accuracy, if the pod has been deleted /cc /priority important-soon /assign /sig scheduling
I think we can update the event handler for deleting pods to reject the pod. Can you send a PR for that?
OKI will send a pr for it.
Change:
"fmt" "reflect" "testing" <del> "time" </del> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/conversion"

Discussion:
https://travis-
Taking a look.
The problem is that TestWatch is using a 10ms timeout, and after parallel test change, we seem to hit the unlucky case more often. This happens when the etcdWatch.translate goroutine never gets a chance to consume the etcdIncoming channel within 10ms. A naive fix would be to remove this 10ms timeout, and have the test rely on the default 30 sec timeout which comes with the test harness.
Ah, I see. Nice catch.
Change:
tolerations: - operator: "Exists" effect: "NoExecute" <ins> - key: "CriticalAddonsOnly" operator: "Exists" </ins>

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): Note: Please file issues for subcomponents under the appropriate repo What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: Currently, the YAML template for both npd and fluentd service do not have toleration, this may cause the daemonset cannot be started on a node if it is already selected to run , it is better to add toleration for both npd and fluentd so as to make sure those daemonset can run on the nodes even if it is for . All other daemonset in kubernetes also have such tolerations. What you expected to happen: Should add toleration for both npd and fluentd. How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
You sent PRs to fix this, right? Can this be closed now?
the PR was not committed yet, can you help lgtm and approve it?
Change:
Creates a replication controller to manage the created container(s). ``` <del> kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=bool] [--overrides=inline-json] </del> <ins> kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=bool] [--overrides=inline-json] [--command] -- [COMMAND] [args...] </ins> ``` ### Examples

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-alpha-enabled-default Which test(s) are failing: CSI hostpath-v0 tests Since when has it been failing: 8/8 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: We are removing CSI 0.3 support in 1.18, which is before selflink is going to be removed in 1.20. So we should just disable hostpath-v0 from alpha tests. /assign
/milestone v1.16
Change:
return false, true, nil } <ins> // `CheckGracefulDelete` will be implemented by specific strategy </ins> if !gracefulStrategy.CheckGracefulDelete(ctx, obj, options) { return false, false, nil } <ins> if options.GracePeriodSeconds == nil { return false, false, errors.NewInternalError(fmt.Errorf("options.GracePeriodSeconds should not be nil")) } </ins> now := metav1.NewTime(metav1.Now().Add(time.Second * time.Duration(*options.GracePeriodSeconds))) objectMeta.SetDeletionTimestamp(&now) objectMeta.SetDeletionGracePeriodSeconds(options.GracePeriodSeconds)

Discussion:
Use apiserver extension(APIService) interface, impl its method to gracefully control resource deletion, when the field is nil, will lead to panic!! To first check if is nil, then get its value. Use apiserver extension(APIService) strategy, impl this function below will lead to panic: As the field is a int64 pointer, need to be careful when init the struct. 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 api-machinery
/triage accepted
Change:
validatingWebhooks []testWebhook expectInvocations  []invocation expectError        bool <del> errorContains      string </del> <ins> errorContainsAnyOf []string </ins> }{ { name:           "minimum of request timeout or webhook timeout propagated",

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: (regardlessoffailurepolicy)and_fail Testgrid link: Reason for failure: and Anything else we need to know: Spyglass: <!-- Please see the deflaking doc () for more guidance! --
/sig api-machinery /area apiserver
Can confirm this PR:
/assign
/triage accepted
The kube-apiserver processing flow is as follows, (non-critical paths are omitted) ... // other filters parse the http client timeout setting, sets the Ctx with Deadline in the http.Request ...// other filters select the http.Request.Context().Done() Pay attention to the processing logic in . Although the Context of http.Request has been cancelled, the Mutex on baseTimeoutWriter needs to be obtained between entering the function. The inner-handler may have written , ready to write , but the current code flow thinks that it should be Panic quickly, and it is recovered by and sends http2.Reset to the Client. As a result, a appears on the client side.
Currently seeing it in periodic and in presubmit for
Regardless of WithCache or WithoutCache, here is not reasonable.
/priority important-soon /milestone v1.21
PS: There were some recent failures:
/remove-priority important-soon /priority critical-urgent top flake for pull-kubernetes-integration per: triage link: FYI
may be one fix, may also be necessary (thanks for opening these
I believe that can effectively repair the issue, but currently is not the key PR to fix the issue.
Change:
// 	}) // }) <del> Describe("ReplicationController", func() { </del> <ins> // These tests take ~20 minutes each. Describe("[Serial] [Slow] ReplicationController", func() { </ins> // CPU tests via replication controllers It(titleUp, func() { scaleUp("rc", kindRC, rc, f)

Discussion:
lightweight test which can be run in gce suite test which verifies that version v1 works
Change:
local tries=5 for i in $(seq 1 $tries); do local output <del> output=$(kubectl "${kube_flags[@]:?}" api-resources --api-group mygroup.example.com -oname) </del> <ins> output=$(kubectl "${kube_flags[@]:?}" api-resources --api-group mygroup.example.com -oname || true) </ins> if kube::test::if_has_string "$output" resources.mygroup.example.com; then break fi

Discussion:
pull-kubernetes-integration: ci-kubernetes-integration-master: [Aa]pply&width=5 runkubectlserversideapplytests Unclear, shows up in flakes in triage history as far back as it goes No response_ Representative failure: /sig api-machinery /cc
If I'm not wrong, SSA conflict error is a real test case and expected(). That test looks failing in I could not find any recent change about that but if there is a latency for discovery endpoint being populated, this test should be flaky for a long time.
Another thing is if we get this not found error from discovery, we are not cleaning it properly and that causes run_crd test fails with already exist.
That's a good point, it's hard to clean-up properly though on failures :-/. And yes, I don't think ssa is the problem here, the problem is in getting the api-resources.
Submitted PR to attempt to fix it, it doesn't solve the clean-up issue, but at least it should hide it well :-)
/triage accepted
Change:
--cluster-monitoring-mode="${KUBE_ENABLE_CLUSTER_MONITORING:-standalone}"  --prometheus-monitoring="${KUBE_ENABLE_PROMETHEUS_MONITORING:-false}"  --dns-domain="${KUBE_DNS_DOMAIN:-cluster.local}"  <ins> --ginkgo.slowSpecThreshold="${GINKGO_SLOW_SPEC_THRESHOLD:-300}"  </ins> ${KUBE_CONTAINER_RUNTIME:+"--container-runtime=${KUBE_CONTAINER_RUNTIME}"}  ${MASTER_OS_DISTRIBUTION:+"--master-os-distro=${MASTER_OS_DISTRIBUTION}"}  ${NODE_OS_DISTRIBUTION:+"--node-os-distro=${NODE_OS_DISTRIBUTION}"} 

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: since we use to run our end to end tests despite nominally being a unit test framework, all tests are "slow test" in the log output due to being greater than the current threshold (default appears to be 5 seconds). What you expected to happen: We should set the threshold to something we consider to be reasonable for an end to end test. What that is might need some thought. /sig testing brought up by
ginkgo does have a we could try setting this in a job and see how it works out before we try to recommend one more generally. WDYT?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /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 : /remove-lifecycle stale /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
This could be as simple as editing:
I can make the change..
Change:
defer conn.Close() h := http.Header{} <del> h.Set("type", "input") </del> <ins> h.Set(api.StreamType, api.StreamTypeError) </ins> stream, err := conn.CreateStream(h) if err != nil { t.Fatalf("error creating input stream: %v", err) } defer stream.Reset() <del> select { case <-conn.CloseChan(): close(idleSuccess) case <-time.After(150 * time.Millisecond): t.Fatalf("Timed out waiting for connection closure due to idle timeout") } </del> <ins> <-conn.CloseChan() </ins> } func TestServeExecInContainer(t *testing.T) {

Discussion:
this is you
Hmm, I had upped waiting from 100ms to 500ms and that seemed to fix it. Do you have any better ideas?
Don't wait? :)
If the only reason you would timeout would be the code is broken, that's why the test runs have -timeout set.
Then the test fails immediately. It's waiting for the net.Listen calls to finish so it can connect to the specified local ports.
*finish enough so that socket connections work
So I can remove the timeout gating in my tests?
Yes ----- Original Message -----
Just failed again: https://travis-
Seems to be failing frequently now.
If this is test is failing again, my gut says it's not the same root cause. The original failure was a timeout issue. This new one is connection reset by peer. I've got the test running in a loop waiting for a failure but haven't seen one yet. is this still failing frequently?
No. It had failed twice in ~10 builds when I reopened this issue, but hasn't failed since. Reclosing. Will file a new issue if it recurs.
Change:
// differentiate probable errors in connection behavior between normal "this is // disconnected" should use the method. func IsProbableEOF(err error) bool { <ins> if err == nil { return false } </ins> if uerr, ok := err.(*url.Error); ok { err = uerr.Err }

Discussion:
https://k8s- /priority failing-test /kind bug /status approved-for-milestone /sig network cc
Fix was opened as
thanks!
Test is still flaky even after the fix. I will take a further look. cc
/assign
looks like now it start to fail on a lot of L7 LB tests
That seems to be a different failure:
The new failure was introduced by When a nil error is passed into , test will panic: Sent for fixing. cc