<p dir="auto">There are several knobs in the plugins used by the fluentd setups, but none of them are exposed to users of the images. It would be great to have that, without requiring custom images: they're more work, tend to rot, etc.</p>
<p dir="auto">I noticed that td-agent.conf supports an <code class="notranslate">@ include</code> directive. Would that work, along with drop-in files in e.g. /etc/td-agent/conf.d/? Is there a way perhaps to inject environment variables into configurations? I can help with PRs once there's agreement on which approach to choose.</p>
<p dir="auto">cc <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/a-robinson/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/a-robinson">@a-robinson</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/jimmidyson/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/jimmidyson">@jimmidyson</a></p>
<p dir="auto"><strong>Kubernetes version</strong>: GitVersion:"v1.3.4+coreos.0", GitCommit:"be9bf3e842a90537e48361aded2872e389e902e7",</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>: AWS</li>
<li><strong>OS</strong> (e.g. from /etc/os-release): CoreOS</li>
<li><strong>Kernel</strong>: Linux ip-10-16-11-222.ec2.internal 4.6.3-coreos <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="35192602" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/2" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/2/hovercard" href="https://github.com/kubernetes/kubernetes/issues/2">#2</a> SMP Fri Aug 5 04:51:16 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz GenuineIntel GNU/Linux</li>
<li><strong>Install tools</strong>: kube-aws</li>
</ul>
<p dir="auto"><strong>What happened</strong>:<br>
I updated a deployment of a pod (a web server) to a version that crashes at runtime. The process still works, but any request will return 500. There is a readiness probe that checks if the server is up. The deployment has one replica, and <code class="notranslate">maxUnavailable: 0, maxSurge: 1</code> rollingUpdate strategy. If I inspect the pods, I see two pods, the old one from the previous deployment, and the new one, both in Running status. After a while, the new one goes in <code class="notranslate">CrashLoopBackOff</code> Even though the new pod never gets healthy the <code class="notranslate">rollout status</code> says "deployment X successfully rolled out". This problem makes it very hard to identify bad deployments. It could be that this is the correct behavior for rollout status, but if it is, I don't know what's a good way to identify that a deployment is gone bad.</p>
<p dir="auto"><strong>What you expected to happen</strong>:<br>
I would expect rollout status to reflect the fact that the deployment didn't succeed. if I <code class="notranslate">describe deployment X</code> I get <code class="notranslate">Replicas:             1 updated | 1 total | 1 available | 1 unavailable</code>, I would also expect <code class="notranslate">updated</code> to be 0, unless I am not understanding correctly what that mean. The rollout status and the updated count are <a href="https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/rollout_status.go#L51">probably related</a>.</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):<br>
Updating a deployment to a new image that fails to pass the readiness probe</p>