<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>.):</p>
<h2 dir="auto">Yes - problems using the FlexVolume<br>
<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.): flexvolume unmount</h2>
<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.4.6<br>
Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.6", GitCommit:"e569a27d02001e343cb68086bc06d47804f62af6", GitTreeState:"clean", BuildDate:"2016-11-12T05:22:15Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"windows/amd64"}<br>
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.6+coreos.0", GitCommit:"ec2b52fabadf824a42b66b6729fe4cff2c62af8c", GitTreeState:"clean", BuildDate:"2016-11-14T19:42:00Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}</p>
<p dir="auto"><strong>Environment</strong>:<br>
CoreOS</p>
<ul dir="auto">
<li>
<p dir="auto"><strong>Cloud provider or hardware configuration</strong>:<br>
local vagrant</p>
</li>
<li>
<p dir="auto"><strong>OS</strong> (e.g. from /etc/os-release):<br>
NAME=CoreOS<br>
ID=coreos<br>
VERSION=1235.0.0<br>
VERSION_ID=1235.0.0<br>
BUILD_ID=2016-11-17-0416<br>
PRETTY_NAME="CoreOS 1235.0.0 (MoreOS)"<br>
ANSI_COLOR="1;32"<br>
HOME_URL="<a href="https://coreos.com/" rel="nofollow">https://coreos.com/</a>"<br>
BUG_REPORT_URL="<a href="https://github.com/coreos/bugs/issues">https://github.com/coreos/bugs/issues</a>"</p>
</li>
<li>
<p dir="auto"><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>):<br>
Linux w1 4.8.6-coreos <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="35192559" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/1" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/1/hovercard" href="https://github.com/kubernetes/kubernetes/issues/1">#1</a> SMP Thu Nov 17 04:07:44 UTC 2016 x86_64 Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz GenuineIntel GNU/Linux</p>
</li>
<li>
<p dir="auto"><strong>Install tools</strong>:<br>
<a href="https://github.com/coreos/coreos-kubernetes">https://github.com/coreos/coreos-kubernetes</a></p>
</li>
<li>
<p dir="auto"><strong>Others</strong>:</p>
</li>
</ul>
<p dir="auto"><strong>What happened</strong>:<br>
I added a FlexVolume driver having looked at the example here <a href="https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/flexvolume">https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/flexvolume</a><br>
After experiencing issues with my driver I reverted it to a skeletal test driver to simply print out calls inbound (please see attached 'skel' script)<br>
<a href="https://github.com/kubernetes/kubernetes/files/619184/skel.txt">skel.txt</a></p>
<p dir="auto">When I test my pod with my volume and the steps below it will init and mount ok but there seems to be no call made to unmount when I test deleting the pod.</p>
<p dir="auto"><strong>What you expected to happen</strong>:<br>
When starting a pod with a the flex volume we should see a log that the mount was called and when I delete the pod I should see a log file entry for the unmount showing that my drivers unmount function has been called.</p>
<p dir="auto">$ cat /tmp/skel.log<br>
Running init<br>
Running mount on path /var/lib/kubelet/pods/c58d27e7-b62f-11e6-b279-080027126f56/volumes/zopa.com~splunk/test on {"kubernetes.io/fsType":"ext4","kubernetes.io/readwrite":"rw"}<br>
Running umount with path /var/lib/kubelet/pods/c58d27e7-b62f-11e6-b279-080027126f56/volumes/zopa.com~splunk/test</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):</p>
<p dir="auto">Add the plugin to the kubelet $VOLUME_PLUGIN_DIR/zopa.com~skel/skel then start the pod: -<br>
<a href="https://github.com/kubernetes/kubernetes/files/619275/skeltest.yaml.txt">skeltest.yaml.txt</a></p>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>
<p dir="auto">See here for filtered kubelet -v 5 logs from the creation of the test pod and it's deletion and the logs to /tmp/skel.log<br>
<a href="https://github.com/kubernetes/kubernetes/files/619269/skel_logs.txt">skel_logs.txt</a></p>
<p dir="auto">Forked from <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="46692646" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/1980" data-hovercard-type="pull_request" data-hovercard-url="/kubernetes/kubernetes/pull/1980/hovercard" href="https://github.com/kubernetes/kubernetes/pull/1980">#1980</a>.</p>
<p dir="auto">The API has a number of lists containing names embedded in objects, such as Volumes, Containers, Ports, Env, and VolumeMounts. Both configuration and field references (e.g., in filter expressions, events) are uglier and/or more verbose when using lists rather than maps. This puts us at a disadvantage compared to other systems with more elegant API and/or configuration schemas (e.g., Fig).</p>
<p dir="auto">Automatically translating maps into lists of named objects appears to be hard. In JSON and YAML, structures and maps cannot be distinguished without a schema. It looks like we'd need either duplicate fields, duplicate schemas, or a custom parser in order to support both formats in the same API version. Duplicate schemas have proven hard to maintain, both in Kubernetes and internally. I don't think we want to maintain parallel API versions forever, either. The go-yaml parser is around 9k lines of code -- a custom parser is not something we want to own, IMO.</p>
<p dir="auto">The specific proposal here is to:</p>
<ul dir="auto">
<li>change these lists to maps</li>
<li>make these name fields optional and auto-populate them from map keys in apiserver, so that names are available in subobjects even without the maps to which they belong</li>
</ul>
<p dir="auto">Port name is currently optional. It would effectively be required. A convention of "p" would be straightforward for users/tools, however, such as in the case of ports auto-populated from Docker images (e.g., by podex).</p>
<p dir="auto">This would be a breaking change. We could do it in v1beta3.</p>
<p dir="auto">The names of top-level objects, in ObjectMeta in v1beta3, would not be changed. Those can be auto-populated in v1beta3 by clients in a straightforward manner.</p>
<p dir="auto">/cc <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/smarterclayton/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/smarterclayton">@smarterclayton</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/erictune/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/erictune">@erictune</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/proppy/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/proppy">@proppy</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/thockin/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/thockin">@thockin</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/jbeda/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/jbeda">@jbeda</a></p>