anchor.diff:   to define and create the PVC.
   
   ----
  -# oc create  -f glusterfs-ep.yaml
  +# oc create -f glusterfs-ep.yaml
   endpoints "glusterfs-cluster" created
   # oc create -f glusterfs-pv.yaml
   persistentvolume "gluster-volume" created
  
positive.code: ====
  For this example, we will be using modified
  xref:../persistent_storage/persistent_storage_glusterfs.adoc#install-config-persistent-storage-persistent-storage-glusterfs[GlusterFS]
  PV and PVC specifications. However, implementation of selectors and labels is
  the same for all storage options.See the
  xref:../persistent_storage/index.adoc#install-config-persistent-storage-index[relevant
  storage option] for your volume provider to learn more about its unique
  configuration.
  
negative.code:   accessModes:
      - ReadWriteMany
    glusterfs:
      endpoints: glusterfs-cluster <2>
      path: myVol1
      readOnly: false
    persistentVolumeReclaimPolicy: Retain
  ----
  <1> Use labels to identify common attributes or characteristics shared among
   volumes. In this case, we've defined the gluster volume to have a custom attribute
   (key) named "storage-tier" with a value of "gold" assigned. A claim will be
   able to select a PV with "storage-tier=gold" to match this PV.
  
  <2> endpoints define the gluster trusted pool and are discussed below.
  ====
  
  [[binding-pv-by-label-pvc-with-selectors]]
  ==== Persistent Volume Claim with Selectors
  
  A claim with a *selector* stanza (see example below) attempts to match existing,
  unclaimed, and non-prebound PVs. The existence of a PVC selector ignores a PV's
  capacity; however, *accessModes* are still considered in the matching criteria.
  
  It is important to note that a claim must match *all* of the key-value pairs
  included in its *selector* stanza. If no PV matches the claim then the PVC
  will remain unbound (Pending). A PV can subsequently be created and the 
  claim will automatically check for a label match.
  
  .glusterfs-pvc.yaml
  ====
  