Initial framework for external volumes. 

Lays the framework for external volume mounts, preparing for 
persistent disks and other volumes.

Currently, it only supports host directory mounts.

Modifies the API to support host directory mounts from Volumes
instead of VolumeMounts.

On Tue, Jul 15, 2014 at 4:51 PM, Clayton Coleman
<notifications@github.com> wrote:
>
> In pkg/kubelet/kubelet.go:
>
> > @@ -69,6 +70,7 @@ type Kubelet struct {
> >   HTTPCheckFrequency time.Duration
> >   pullLock           sync.Mutex
> >   HealthChecker      HealthChecker
> > + extVolumes   map[string]volumes.Interface
>
> The problem of temporarily unavailable manifests also exists on startup (races between different sources
> starting at different times) - and in protracted partitions from etcd. Caching the last known good
> configuration state may still potentially miss a volume allocation, so it seems that some volume
> reconciliation loop is necessary.

Explain how it could miss a volume?  If Kubelet caches the state that
it knows it enacted ... what am I missing?

> As a related note, we would eventually like to support quasi stable volumes across pod deletes (to allow
> for moves to occur on stopped data) - in those cases we likely would want a volume type that is
> explicitly garbage collected within a policy window, so we can reasonably delete a pod and invoke a side
> channel API to move those volumes. Having the volume reconciliation loop be modeled helps deal with
> those kinds of edge cases.

Interesting use case.

I'll argue that in that case, the pod may be removed from etcd, but
it's really in a "cleanup" state according to kubelet, and it still
exists.