<p dir="auto">Currently you can parametrize a container via environment variables passed in the Pod spec.  Some applications expect their configuration in the form of config files.  The gap can be bridged by a helper script in the container that reads the config from an environment variable and writes it to a file before executing the app, but this is somewhat hackish for large configs.  While Linux support very large environment variables, it would be more natural to pass the config to the container via a file, as the app expects.</p>
<p dir="auto">I propose a new mechanism that would allow you to specify a config file within the spec and have the file mounted at the specified location within the container.  This would work similar to a hostPath volume, but it would not require that the file pre-exist in the node the Pod executes in, and would delete the file once the Pod no longer runs.</p>
<p dir="auto">Maybe something like:</p>
<div class="highlight highlight-source-yaml notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /etc/some.config
      name: config-file
  volumes:
  - name: config-file
    inlineFile:
      content: |
        foo = bar
        x = y"><pre class="notranslate"><span class="pl-ent">apiVersion</span>: <span class="pl-c1">v1</span>
<span class="pl-ent">kind</span>: <span class="pl-s">Pod</span>
<span class="pl-ent">metadata</span>:
  <span class="pl-ent">name</span>: <span class="pl-s">test</span>
<span class="pl-ent">spec</span>:
  <span class="pl-ent">containers</span>:
  - <span class="pl-ent">image</span>: <span class="pl-s">gcr.io/google_containers/test-webserver</span>
    <span class="pl-ent">name</span>: <span class="pl-s">test-container</span>
    <span class="pl-ent">volumeMounts</span>:
    - <span class="pl-ent">mountPath</span>: <span class="pl-s">/etc/some.config</span>
      <span class="pl-ent">name</span>: <span class="pl-s">config-file</span>
  <span class="pl-ent">volumes</span>:
  - <span class="pl-ent">name</span>: <span class="pl-s">config-file</span>
    <span class="pl-ent">inlineFile</span>:
      <span class="pl-ent">content</span>: <span class="pl-s">|</span>
<span class="pl-s">        foo = bar</span>
<span class="pl-s">        x = y</span></pre></div>
<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.): No</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.): pod status failed volume</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one): BUG REPORT</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>): 1.3.5</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> (e.g. <code class="notranslate">uname -a</code>): <code class="notranslate">Linux ip-10-20-8-69.us-west-2.compute.internal 4.3.3-coreos #2 SMP Thu Dec 17 23:57:55 UTC 2015 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux</code></li>
<li><strong>Install tools</strong>: Custom</li>
<li><strong>Others</strong>:</li>
</ul>
<p dir="auto"><strong>What happened</strong>:<br>
A pod entered the "Failed" status because the node ran out of disk:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="  status:
    message: Pod cannot be started due to lack of disk space.
    phase: Failed
    reason: OutOfDisk
    startTime: 2016-09-27T21:23:04Z"><pre class="notranslate"><code class="notranslate">  status:
    message: Pod cannot be started due to lack of disk space.
    phase: Failed
    reason: OutOfDisk
    startTime: 2016-09-27T21:23:04Z
</code></pre></div>
<p dir="auto">A new pod was started (it is part of a deployment), but the failed pod was still holding on to the EBS volume, which the kubelet didn't release until I explicitly deleted the failed pod with <code class="notranslate">kubectl delete</code>.</p>
<p dir="auto"><strong>What you expected to happen</strong>:<br>
The failed pod should not hold on to the volume or otherwise prevent the new pod from running in any way.</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):<br>
I have not tried to reproduce it.</p>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>