anchor.diff:  plug-in is defined.
   <5> This references the endpoints named above.
   <6> This is the Gluster volume name, preceded by `/`.
  -<7> A volume reclaim policy of *retain* indicates that the volume will be
  -preserved after the pods accessing it terminate. Accepted values include (Retain, Delete and Recycle)
  +<7> A volume reclaim policy of *retain* indicates that the volume will be preserved
  +after the pods accessing it terminate. Accepted values include Retain, Delete,
  +and Recycle.
   ====
   
   Save the PV definition to a file, for example *_gluster-pv.yaml_*,
  
positive.code:       claimName: gluster-claim      <6>
  ----
  <1> The name of this pod as displayed by `oc get pod`.
  <2> The image run by this pod. In this case, we are using standard ngnix image.
  <3> The name of the volume. This name must be the same in both the
  `*containers*` and `*volumes*` sections.
  <4> The mount path as seen in the container.
  <5> The SupplementalGroup ID (Linux Groups) to be assigned at the pod level 
  and as discussed this should match the POSIX permissions on the gluster volume.
  <6> The PVC that is bound to the Gluster cluster.
  ====
  
  
negative.code: 
  [NOTE]
  ====
  The NGINX image may require to run in privileged mode to create the mount and
  run properly. An easy way to accomplish this is to simply add your user to the
  *privileged* Security Context Constraint (SCC):
  ----
  $ oadm policy add-scc-to-user privileged myuser
  ----
  
  Then, add the *privileged: true* to the containers `*securityContext:*` section
  of the YAML file (as seen in the example below).
  
  xref:../../admin_guide/manage_scc.adoc#admin-guide-manage-scc[Managing Security
  Context Constraints] provides additional information regarding SCCs.
  ====
  
  .Pod Object Definition using NGINX image
  