anchor.diff:  
   [[gfs-creating-pvc]]
   === Creating the Persistent Volume Claim
  -Developers request GlusterFS storage by referencing, in the `*volumes*` section
  -of their pod spec, either a
  -link:../../dev_guide/persistent_volumes.html[`*PersistentVolumeClaim*`] by name,
  -or the gluster volume plug-in directly. A PVC exists only in the user's project
  -and can only be referenced only by pods within that same project. Any attempt to
  -access a PV across a project causes the pod to fail.
  -
  -The next step is to create a persistent volume claim (PVC) which will bind
  -to the new PV:
  -
  +Developers request GlusterFS storage by referencing either a PVC or the Gluster
  +volume plug-in directly in the `*volumes*` section of a pod spec. A PVC exists
  +only in the user's project and can only be referenced by pods within that
  +project. Any attempt to access a PV across a project causes the pod to fail.
  +
  +. Create a PVC that will bind to the new PV:
  ++
   .PVC Object Definition
   ====
   [source,yaml]
  
positive.code: 
  [NOTE]
  ====
  It is generally preferable to use link:#gfs-supplemental-groups[supplemental
  group IDs] to gain access to persistent storage versus using user IDs.
  ====
  
  In the link:#gfs-mount[example target gluster mount] shown above, the container
  needs its UID set to 592 (ignoring group IDs for the moment), so the following
  can be added to the pod definition:
  
  ====
  [source,yaml]
  
negative.code:     ports:
        - port: 1 <3>
  ----
  <1> This name must match the service name from step 1.
  <2> The `*ip*` values must be the actual IP addresses of a Gluster server, not
  fully-qualified host names.
  <3> The port number is ignored.
  ====
  
  . Save the endpoints definition to a file, for example
  *_gluster-endpoints.yaml_*, then create the endpoints:
  +
  ====
  ----
  $ oc create -f gluster-endpoints.yaml
  