Issue 1:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

Yes - problems using the FlexVolume

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): flexvolume unmount

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Kubernetes version (use kubectl version): 1.4.6

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"}

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"}

Environment:

CoreOS

Cloud provider or hardware configuration:

local vagrant

OS (e.g. from /etc/os-release):

NAME=CoreOS

ID=coreos

VERSION=1235.0.0

VERSION_ID=1235.0.0

BUILD_ID=2016-11-17-0416

PRETTY_NAME="CoreOS 1235.0.0 (MoreOS)"

ANSI_COLOR="1;32"

HOME_URL="https://coreos.com/"

BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

Kernel (e.g. uname -a):

Linux w1 4.8.6-coreos #1 SMP Thu Nov 17 04:07:44 UTC 2016 x86_64 Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz GenuineIntel GNU/Linux

Install tools:

https://github.com/coreos/coreos-kubernetes

Others:

What happened:

I added a FlexVolume driver having looked at the example here https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/flexvolume

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)

skel.txt

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.

What you expected to happen:

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.

$ cat /tmp/skel.log

Running init

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"}

Running umount with path /var/lib/kubelet/pods/c58d27e7-b62f-11e6-b279-080027126f56/volumes/zopa.com~splunk/test

How to reproduce it (as minimally and precisely as possible):

Add the plugin to the kubelet $VOLUME_PLUGIN_DIR/zopa.com~skel/skel then start the pod: -

skeltest.yaml.txt

Anything else do we need to know:

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

skel_logs.txt

Issue 2:
Forked from #1980.

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).

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.

The specific proposal here is to:

change these lists to maps

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

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).

This would be a breaking change. We could do it in v1beta3.

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.

/cc @smarterclayton @erictune @proppy @thockin @jbeda