Change:
This test is failing in gce serial suite: http://k8s- /sig cluster-lifecycle /priority failing-test /priority critical-urgent /kind bug /status approved-for-milestone cc /assign xref
/milestone v1.10
this also fails in upgrade suite xref
looks like is now green. guess it's still flaky
not from http://k8s-
oh, probably pasted wrong link in the issue body? my bad
ah cool.
Mar 7 16:52:36.943: At least one pod wasn't running and ready or succeeded at test start. ^ The preconditions are not met at the start of the test... and the pods state shows as pending. Always seems to be a fluentd pod on the master node doesn't run. Are things tainted properly? /cc & as they are the test authors.
/assign /assign
GitHub didn't allow me to assign the following users: mbforbes. Note that only and repo collaborators can be assigned. <detailsIn response to : /assign /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
FWIW, I didn't author the test, and the test didn't even run since it failed the precondition.... /unassign /assign /assign fluentd pods are pending on the master nodes.
GitHub didn't allow me to assign the following users: bmoyles0117. Note that only and repo collaborators can be assigned. <detailsIn response to : FWIW, I didn't author the test, and the test didn't even run since it failed the precondition.... /assign /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
status?
ping
Looking into it
I have some problems with running e2e tests locally Could you please take a look? I will return to this tomorrow Europe time
I'm not sure what exactly is failing here. I was hoping to see if the two PRs we merged previously would have a positive impact on these failures. Is there any way of seeing whether or not those two PRs did or did not have a positive impact? The two PRs for context are:
made DaemonSet controller schedules pods on "unschedulable" nodes. The changes lets the fluentd pod to be scheduled on the master, but there is no capacity on the master node to run this pod. /cc
is enabled by default: if node is 'unschedulable' ( is true), the pod will not schedule to it. already includes this check; is used to also enable this check when enabled.
/status in-progress
any solution here?
fluentd is scheduled on the master node, which is marked unschedulable (). Is this working as intended?
Yes, assuming fluentd is a DaemonSet pod. is nothing new; it's introduced to fix a regression in 1.10 (). As stated in DaemonSet :
If fluentd Daemon pod isn't supposed to be scheduled on the master, taints should be to the master; if instead it should be scheduled on the master, we should add more capacity to the master node.
fluentd's asking more cpu resources than 1.9 (the regression caused by masked the issue until now). Seems like this could be related to the introduction of fluentd-gcp-scaler. /assign
That's unexpected, thanks for noticing /assign Daniel, please take a look
fluentd-gcp in both 1.9 and 1.10 asks for the same amount of resources: 100m cpu request, 200Mi memory request (and 300Mi memory limit). Introducing fluentd-gcp-scaler didn't change these values. Do you mean that CPU request increased? I see it is 100m now (as it was for 1.9), what values did you see for 1.9 and now?
any updates?
The fluentd pod on the master from https://k8s- Both the and the containers request 100m cpu This amounts to 200m cpu. In v1.9, did not have any cpu request IIRC. You can double check that.
Thanks! Looks like there is a bug in the scaler, so it sets resources on all containers instead of fluentd-gcp only. Scaler fix is in , I will create a PR with version bump once this is merged.
Actually, maybe better to /reopen until testgrid becomes green.
ACK. In progress ETA: 19/03/2018
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
https://k8s- is green now

Discussion:
namespace: kube-system labels: k8s-app: fluentd-gcp-scaler <del> version: v0.2.0 </del> <ins> version: v0.3.0 </ins> addonmanager.kubernetes.io/mode: Reconcile spec: selector:

serviceAccountName: fluentd-gcp-scaler containers: - name: fluentd-gcp-scaler <del> image: gcr.io/google-containers/fluentd-gcp-scaler:0.2 </del> <ins> image: gcr.io/google-containers/fluentd-gcp-scaler:0.3 </ins> command: - /scaler.sh - --ds-name=fluentd-gcp-v3.0.0