<p dir="auto">Currently we have "GCEPersistentDisk", and this name is exposed via the API.  I am working on adding support for AWS EBS, which is very similar to GCEPersistentDisk.</p>
<p dir="auto">Should I add another type AWSPersistentDisk, or should we try to make GCEPersistentDisk work for any PD/EBS/Cinder style cloud-block device?  (And presumably rename GCEPersistentDisk to CloudPersistentDisk or something similar)</p>
<p dir="auto">On EC2, EBS volumes are bound to a specific AZ, so I think we'll likely have a "cloud location" specifier even if we have AWSPersistentDisk (cloudLocation: us-west-2b).  I'm thinking if we're going to do that, we might as well have "cloudLocation: aws/us-west-2b", in which case there seems less reason to have the different types.</p>
<p dir="auto">My personal preference would be to have one PersistentDisk type for all the clouds, to avoid code duplication; it also feels like a simpler API to consume.</p>
<h3 dir="auto">Bug Report</h3>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>): v1.4.6, v1.5.0-beta.2</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>: OpenStack</li>
<li><strong>OS</strong> (e.g. from /etc/os-release): Centos7</li>
</ul>
<p dir="auto"><strong>What happened</strong>: When kubernetes relocates a pod that has a persistent volume from cinder, the pod will never start because the volume cannot be attached as it is already attached to another node.</p>
<p dir="auto"><strong>What you expected to happen</strong>: Kubernetes should detach the volume from old node and attach it to new node and then start the pod.</p>
<p dir="auto"><strong>How to reproduce it</strong>: Have 2 nodes in the same AZ. Create a pod with a cinder volume. Shut down the node where the pod is running. Pod relocates to another node but fails to start as volume never detaches from the original node.</p>
<p dir="auto"><strong>Anything else do we need to know</strong>: Pod relocation can happen for failed nodes or if a pod is deleted on a perfectly functional node. Thus, detach should occur if required, no matter what state the original node is in. Attach is handled in: pkg/cloudprovider/providers/openstack/openstack_volumes.go. Volume detach is never attempted if disk is attached to a different compute, leading to an infinite failure loop (even if failed node recovers):</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="if len(disk.Attachments) &gt; 0 &amp;&amp; disk.Attachments[0][&quot;server_id&quot;] != nil {
	if instanceID == disk.Attachments[0][&quot;server_id&quot;] {
		glog.V(4).Infof(&quot;Disk: %q is already attached to compute: %q&quot;, diskName, instanceID)
		return disk.ID, nil
	} else {
		errMsg := fmt.Sprintf(&quot;Disk %q is attached to a different compute: %q, should be detached before proceeding&quot;, diskName, disk.Attachments[0][&quot;server_id&quot;])
		glog.Errorf(errMsg)
		return &quot;&quot;, errors.New(errMsg)
	}
}"><pre class="notranslate"><code class="notranslate">if len(disk.Attachments) &gt; 0 &amp;&amp; disk.Attachments[0]["server_id"] != nil {
	if instanceID == disk.Attachments[0]["server_id"] {
		glog.V(4).Infof("Disk: %q is already attached to compute: %q", diskName, instanceID)
		return disk.ID, nil
	} else {
		errMsg := fmt.Sprintf("Disk %q is attached to a different compute: %q, should be detached before proceeding", diskName, disk.Attachments[0]["server_id"])
		glog.Errorf(errMsg)
		return "", errors.New(errMsg)
	}
}
</code></pre></div>