anchor.diff:  
   A `PersistentVolume` (PV) is a piece of networked storage in the cluster that has been provisioned by an administrator.  It is a resource in the cluster just like a node is a cluster resource.   PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV.  This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
   
  -A `PersistentVolumeClaim` (PVC) is a request for storage by a user.  It is similar to a pod.  Pods consume node resources and PVCs consume PV resources.  Pods can request specific levels of resources (CPU and Memory).  Claims can request specific size and access modes (e.g, can be mounted once read/write or many times read-only).
  +A `PersistentVolumeClaim` (PVC) is a request for storage by a user.  It is similar to a pod.  Pods consume node resources and PVCs consume PV resources.  Pods can request specific levels of resources (CPU and Memory).  Claims can request specific storage capacity and access modes (e.g, can be mounted once read/write or many times read-only).
   
   == Lifecycle of a volume and claim
   
  -PVs are resources in the cluster.  PVC are requests for those resources and also act as claim checks to the resource.  The interaction between PVs and PVCs follows this lifecycle:
  +PVs are resources in the cluster.  PVCs are requests for those resources and also act as claim checks to the resource.  The interaction between PVs and PVCs follows this lifecycle:
   
   === Provisioning
   
  
positive.code: 
  A volume will be in one of the following phases:
  
  * Available -- a free resource resource that is not yet bound to a claim
  * Bound -- the volume is bound to a claim
  * Released -- the claim has been deleted, but the resource is not yet reclaimed by the cluster
  * Failed -- the volume has failed its automatic reclamation
  
negative.code: 
  Pods use claims as volumes. The cluster inspects the claim to find the bound volume and mounts that volume for a pod.  For those volumes that support multiple access modes, the user specifies which mode desired when using their claim as a volume in a pod.
  
  Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as she needs it. Users schedule Pods and access their claimed PVs by including a persistentVolumeClaim in their Pod's volumes block. See link:#claims-as-volumes[below] for syntax details.
  
  === Releasing
  
  When a user is done with a volume, they can delete the PVC object from the API which allows reclamation of the resource.  The volume is considered "released" when the claim is deleted, but it is not yet available for another claim.  The previous claimant's data remains on the volume which must be handled according to policy.
  
  === Reclaiming
  
  The reclaim policy of a `PersistentVolume` tells the cluster what to do with the volume after it's released.  Currently, volumes can either be Retained or Recycled.  Retention allows for manual reclamation of the resource.  For those volume plugins that support it, recycling performs a basic scrub ("rm -rf /thevolume/*") on the volume and makes it available again for a new claim.
  
  == Persistent Volumes
  
  == Types of Persistent Volumes
  
  OpenShift currently supports the following `PersistentVolume` plugins:
  
  * NFS
  * GCEPersistentDisk
  * AWSElasticBlockStore
  * HostPath (single node testing only)
  
  More plugins are available but still under development:
  
  * Glusterfs
  * iSCSI
  * RBD (Ceph Block Device)
  
  Each PV contains a spec and status, which is the specification and status of the volume.
  
  